BUG #19024: Error when trying to use pg_dump of new server on old server
The following bug has been logged on the website:
Bug reference: 19024
Logged by: Egor Chindyaskin
Email address: kyzevan23@mail.ru
PostgreSQL version: 17.6
Operating system: Ubuntu 25.04
Description:
Hello, commit 6b755d8d70b2ceffeb4798cbb6907d2704c2e6c4 introduced a new bug.
If you take the old cluster and server and try to do a pg_dump on the new
server REL_17_STABLE (71ee96e9f95806f9f6e2c805496c0dcf25b3946a), as shown in
the reproduction below:
#!/bin/bash
PG_OLD=REL_17_0/bin
PG_NEW=REL_17_STABLE/bin
$PG_OLD/initdb -D data
$PG_OLD/pg_ctl -D data -l logfile start
$PG_OLD/dropdb testdb > /dev/null || true
$PG_OLD/createdb testdb
$PG_OLD/psql -c "CREATE DOMAIN public.hstestdom1 AS integer NOT NULL DEFAULT
0;" testdb
$PG_NEW/pg_dump testdb
We will get the error
pg_dump: error: query failed: ERROR: invalid constraint type "n"
pg_dump: detail: Query was: EXECUTE getDomainConstraints('16386')
---
Best regards,
Egor Chindyaskin
Postgres Professional: http://postgrespro.com
On Tue, 19 Aug 2025 at 16:34, PG Bug reporting form
<noreply@postgresql.org> wrote:
The following bug has been logged on the website:
Bug reference: 19024
Logged by: Egor Chindyaskin
Email address: kyzevan23@mail.ru
PostgreSQL version: 17.6
Operating system: Ubuntu 25.04
Description:Hello, commit 6b755d8d70b2ceffeb4798cbb6907d2704c2e6c4 introduced a new bug.
If you take the old cluster and server and try to do a pg_dump on the new
server REL_17_STABLE (71ee96e9f95806f9f6e2c805496c0dcf25b3946a), as shown in
the reproduction below:#!/bin/bash
PG_OLD=REL_17_0/bin
PG_NEW=REL_17_STABLE/bin
$PG_OLD/initdb -D data
$PG_OLD/pg_ctl -D data -l logfile start
$PG_OLD/dropdb testdb > /dev/null || true
$PG_OLD/createdb testdb
$PG_OLD/psql -c "CREATE DOMAIN public.hstestdom1 AS integer NOT NULL DEFAULT
0;" testdb
$PG_NEW/pg_dump testdbWe will get the error
pg_dump: error: query failed: ERROR: invalid constraint type "n"
pg_dump: detail: Query was: EXECUTE getDomainConstraints('16386')---
Best regards,
Egor Chindyaskin
Postgres Professional: http://postgrespro.com
Hi!
6e79358 fixed server support for pg_get_constraintdef, so you should
use pg >= 17.3 for this test to work.
pd_dump executes queries on server, so NEW pg_dump will execute on OLD
server. We cannot change anything in 17.0 to make this example work.
So nothing need to be done for REL_17_STABLE?
--
Best regards,
Kirill Reshke
On Tue, 19 Aug 2025 at 17:54, Kirill Reshke <reshkekirill@gmail.com> wrote:
Hi!
6e79358 fixed server support for pg_get_constraintdef, so you should
use pg >= 17.3 for this test to work.
pd_dump executes queries on server, so NEW pg_dump will execute on OLD
server. We cannot change anything in 17.0 to make this example work.
So nothing need to be done for REL_17_STABLE?
I will clarify a little here. The only way to fix this is to add new
code to REL_17_STABLE for pg version >= 170000 and < 170003.
Something like, "if postgresql in pg 17 with bug in
pg_get_constraintdef, do not call pg_get_constraintdef for contype =
'n', but describe it using pg_dump code"
This is a very difficult solution to maintain in-core, so the only
advice I can give is no actually update the minor version of the
server.
--
Best regards,
Kirill Reshke
Kirill Reshke <reshkekirill@gmail.com> writes:
I will clarify a little here. The only way to fix this is to add new
code to REL_17_STABLE for pg version >= 170000 and < 170003.
Something like, "if postgresql in pg 17 with bug in
pg_get_constraintdef, do not call pg_get_constraintdef for contype =
'n', but describe it using pg_dump code"
This is a very difficult solution to maintain in-core, so the only
advice I can give is no actually update the minor version of the
server.
No, we're not going to do that. The correct answer here is "update to
a supported version of the server", namely the latest minor release.
regards, tom lane