Re: pg_dump assertion failure with "-n pg_catalog"

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Jeff Davis <pgsql(at)j-davis(dot)com>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: pg_dump assertion failure with "-n pg_catalog"
Date: 2023-06-12 06:52:40
Message-ID: ZIbAuHfnWY05VxVt@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Heikki Linnakangas 2023-06-12 09:13:53 Re: BUG #17946: LC_MONETARY & DO LANGUAGE plperl - BUG
Previous Message Michael Paquier 2023-06-12 05:25:12 Re: BUG #17962: postgresql 11 hangs on poly_contain with specific data