Re: pg_dump assertion failure with "-n pg_catalog" - Mailing list pgsql-bugs

From Michael Paquier
Subject Re: pg_dump assertion failure with "-n pg_catalog"
Date
Msg-id ZIbAuHfnWY05VxVt@paquier.xyz
Whole thread Raw
In response to pg_dump assertion failure with "-n pg_catalog"  (Jeff Davis <pgsql@j-davis.com>)
Responses Re: pg_dump assertion failure with "-n pg_catalog"  (Jeff Davis <pgsql@j-davis.com>)
List pgsql-bugs
On Wed, Jun 07, 2023 at 10:36:29AM -0700, Jeff Davis wrote:
> If we went almost two release cycles without anyone noticing, then
> perhaps we should just get rid of the ability to dump pg_catalog. But I
> think the attached patch clarifies things regardless.

That looks correct for v15 and HEAD, not when dumping from older
versions.

Attempting the same command with a patched pg_dump on ~14 triggers
more failures.  The first assertion hit is this one, for instance:
$ pg_dump -n pg_catalog
pg_dump: pg_dump.c:13460: dumpCollation: Assertion `colliculocale != ((void *)0)' failed.

colliculocale and collicurules don't exist there, but the code is
forcing the value to NULL as PQfnumber() returns -1 for an attribute
that does not exist.

else if (collprovider[0] == 'i')
{
+       Assert(colliculocale != NULL);
+       Assert(collcollate == NULL);
+       Assert(collctype == NULL);

If ICU provides the collation, colliculocale is NULL when dumping from
~14, while both collcollate and collctype are not NULL.  Hence all
three assertions are incorrect for ~14, while they are correct for
15~.  It seems to me that you are going to require a per-version
handling here if you wish to keep collprovider on top of the rest.

I'd like to agree with you about the fact that having collprovider
handled before the rest makes things easier to follow in the future.
At least that's my feeling after looking at your patch.
--
Michael

Attachment

pgsql-bugs by date:

Previous
From: Michael Paquier
Date:
Subject: Re: BUG #17962: postgresql 11 hangs on poly_contain with specific data
Next
From: Heikki Linnakangas
Date:
Subject: Re: BUG #17946: LC_MONETARY & DO LANGUAGE plperl - BUG