Обсуждение: 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 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
>

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