Operations/Minutes/2026-08-06

OpenStreetMap Foundation, Operations Meeting - Draft minutes

These minutes do not go through a formal acceptance process.
This is not strictly an Operations Working Group (OWG) meeting.

Thursday 6 August 2026, 19:00 London time
Location: Video room at https://osmvideo.cloud68.co

Participants

Minutes by Dorothea Kazazi.

New action items from this meeting

Tom to update the notes on how to perform Postgres version upgrades. For major Postgres versions we have to run stanza-upgrade on the repository before we start up the new version of Postgres. Does not apply for point releases.[Topic: pgBackRest upgrades]
OPS to do test on one of the slave servers and as part of that test a pgBackRest restore. [Topic: pgBackRest upgrades]
OPS to decide whether to enable page checksums. This will be decoupled from the pgBackRest upgrade, as it requires significant downtime. [Topic: pgBackRest upgrades]
Rubén to do a storage comparison experiment using traces of various sizes, load them into a database in the current schema and as LineStrings, and compare table sizes. [Topic: GPS points database table]

Dublin data center site visit

We still need a name for the QGIS sponsored tile server.

Grant will travel to the Dublin data center on Saturday for infrastructure maintenance.

Tasks

Change the out-of-band Raspberry Pi to match the Amsterdam one.
Install the new power switching device for the Raspberry Pis.
De-rack two old servers.
Rack the new QGIS-sponsored tile render server.
Replace the 4G modem antenna with a significantly better one and reposition it.
Replace an interlink cable between the two PDUs with a lower quality one. The replacement will not be a Cat6 but likely an aluminum Ethernet cable.
Replace a memory DIMM in Smaug (Nominatim machine).

pgBackRest upgrades

Backups

Scheduled backup now runs on a Thursday to avoid existing pg_backup
The first automated full backup is currently running and is 46% complete. It should finish around lunchtime tomorrow. It is expected to take approximately 36 hours.Subsequent backups should take less than 12 hours.

There is a new minor version pgBackRest upgrade available. We are running the version from the Postgres repository, not the Debian one.

For restoration The Postgres version has to match for restoration, otherwise replacement of the WAL log files throws an error.

Suggestions

Enabling page checksums (a Postgres 18 feature).
- This will require tens of hours of downtime.

Action items

Tom to update the notes on how to perform Postgres version upgrades. For major Postgres versions we have to run stanza-upgrade on the repository before we start up the new version of Postgres. Does not apply for point releases.
OPS to do test on one of the slave servers and as part of that test a pgBackRest restore.
OPS to decide whether to enable page checksums. This will be decoupled from the pgBackRest upgrade, as it requires significant downtime.

GPS points database table

As part of the GPX modernization, is there space in the server/database for a table where gps_points could be stored as a LineString?

Issue: GPS trace pagination is currently blocked because GPS points do not have a primary key.

Suggestions regarding absence of primary key

Use the GPX file ID or track ID plus timestamp.
Use the GPX file ID, possibly plus the track ID, as the cursor and not split pages inside a track. Thus, there would be no concern of using the timestamp in the cursor. Each page would contain either a set number of complete tracks, or roughly a target number of points, always cutting at a track boundary rather than mid-track.

On suggestion to convert the GPS points into LineStrings
Suggestion: convert the GPS points into LineString geometry stored in a new table, to enable pagination and to prepare for future tiling work.

It is unclear whether a LineString / multi-Linestrings or point collection is preferable.
Converting GPS points to LineStrings does not actually make the pagination problem any easier.

Suggestions

Sketch out other things we want to do with LineStrings, e.g. clipping for privacy reasons.
Look at the storage implications and compare the space to store a given trace using LineStrings versus the current schema.

Action item

Rubén to do a storage comparison experiment using traces of various sizes, load them into a database in the current schema and as LineStrings, and compare table sizes.