Backup fails with postgres 18

The database of our discourse instance is not a local container, instead we use a central database cluster. Recently the central postgresql was updated to version 18.3. I noticed that the discourse backup now fails:

[2026-05-19 03:37:37] [STARTED]
[2026-05-19 03:37:37] 'system' has started the backup!
[2026-05-19 03:37:37] Marking backup as running...
[2026-05-19 03:37:37] Making sure '/var/www/discourse/tmp/backups/default/2026-05-19-033737' exists...
[2026-05-19 03:37:37] Making sure '/var/www/discourse/public/backups/default' exists...
[2026-05-19 03:37:37] Updating metadata...
[2026-05-19 03:37:37] Dumping the public schema of the database...
[2026-05-19 03:37:37] pg_dump: error: aborting because of server version mismatch
[2026-05-19 03:37:37] pg_dump: detail: server version: 18.3 (Ubuntu 18.3-1.pgdg24.04+1); pg_dump version: 15.15 (Debian 15.15-1.pgdg12+1)
[2026-05-19 03:37:37] EXCEPTION: pg_dump failed
[2026-05-19 03:37:37] /var/www/discourse/lib/backup_restore/creator.rb:173:in 'BackupRestore::Creator#dump_public_schema'
/var/www/discourse/lib/backup_restore/creator.rb:36:in 'BackupRestore::Creator#run'
/var/www/discourse/lib/backup_restore.rb:13:in 'BackupRestore.backup!'
/var/www/discourse/app/jobs/regular/create_backup.rb:10:in 'Jobs::CreateBackup#execute'

Any ideas how to fix this?

This looks like a PostgreSQL client/server version mismatch.

The backup is being run from the Discourse container, where pg_dump is version 15.15, but the external PostgreSQL server is 18.3:

server version: 18.3; pg_dump version: 15.15

I’d be cautious about modifying the Discourse container unless the Discourse team recommends that. My first instinct would be to keep the external database cluster aligned with the PostgreSQL version Discourse currently expects/supports.

OK, understood. In this case I had no choice as we needed 18 for another project which uses the same database cluster. Hmm, sounds like we would need a separate database server with 15 exclusively for discourse.

Any comments from CDCK side?

Might be possible to upgrade the client in place?

Given you seem to have proved compatibility with PG 18 as you are using it as the production database this would seem low risk.

I made a quick test with an external postgres 18 and a dummy discourse installation before, it showed no issues. But, to be honest, this was only “quick and dirty”, not a “deep” test. Anyway, it runs since 2 weeks, so I assume its fine. The Discourse-internal backup is the only issue so far. On the other hand, the database server itself (running on LXC) is also backuped separately.

The policy in the past has been to upgrade every other version. However, it has been 1.5 years since PostgreSQL 17 was released and the official Docker image still uses 15, so I’m not sure this is still the case.

There are almost identical topics in the past you can reference, e.g.: Any chance to upgrade the postgres-client version?

just a thought - can you dump directly from the command line from the pg server?

You can add code to your app.yml to update postgres to the matching version. I’ve done it before, but can’t find my notes. The easiest thing to do is go into the container, issue the apt commands to get the right postgres clients installed and then try the backup. Once that works, you add those commands to exec commands in your app.yml so that it’ll work after the next rebuild.

If you need someone to walk you though it, you can email me or post in Marketplace.

Hmmm, that was quite simple:

1. ./launcher enter web_only
2. sudo apt-get install postgresql

This upgrades the postgres package to V. 18.
And then start the backup from Admin UI which seems to be successful

[2026-05-21 16:26:50] 'admin' has started the backup!
[2026-05-21 16:26:50] Marking backup as running...
[2026-05-21 16:26:50] Making sure '/var/www/discourse/tmp/backups/default/2026-05-21-162650' exists...
[2026-05-21 16:26:50] Making sure '/var/www/discourse/public/backups/default' exists...
[2026-05-21 16:26:50] Updating metadata...
[2026-05-21 16:26:50] Dumping the public schema of the database...
[2026-05-21 16:26:50] pg_dump: executing SELECT pg_catalog.set_config('search_path', '', false);
[2026-05-21 16:26:50] pg_dump: last built-in OID is 16383
[2026-05-21 16:26:50] pg_dump: reading extensions
[2026-05-21 16:26:50] pg_dump: identifying extension members
[2026-05-21 16:26:50] pg_dump: reading schemas
[2026-05-21 16:26:50] pg_dump: reading user-defined tables
[2026-05-21 16:26:50] pg_dump: reading user-defined functions
[2026-05-21 16:26:50] pg_dump: reading user-defined types
[2026-05-21 16:26:50] pg_dump: reading procedural languages
[2026-05-21 16:26:50] pg_dump: reading user-defined aggregate functions
[2026-05-21 16:26:50] pg_dump: reading user-defined operators
[2026-05-21 16:26:50] pg_dump: reading user-defined access methods
[2026-05-21 16:26:50] pg_dump: reading user-defined operator classes
[2026-05-21 16:26:50] pg_dump: reading user-defined operator families
[... .... ...]
[2026-05-21 16:26:57] Finalizing backup...
[2026-05-21 16:26:57] Creating archive: netzwissen-forum-2026-05-21-162650-v20260520064255.tar.gz
[2026-05-21 16:26:57] Making sure archive does not already exist...
[2026-05-21 16:26:57] Creating empty archive...
[2026-05-21 16:26:57] Archiving data dump...
[2026-05-21 16:26:57] Archiving uploads...
[2026-05-21 16:26:58] Removing tmp '/var/www/discourse/tmp/backups/default/2026-05-21-162650' directory...
[2026-05-21 16:26:58] Gzipping archive, this may take a while...

Nice! I’d probably try to install specifically the pg18 client stuff so that it doesn’t switch to 19 at some point. Also, you’ll want to add these commands to your app.yml, unless you want to do this by hand at every upgrade.