Re: pg_dump assertion failure with "-n pg_catalog"

From: Jeff Davis <pgsql(at)j-davis(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: pg_dump assertion failure with "-n pg_catalog"
Date: 2023-06-15 22:47:59
Message-ID: e7c1adfe66542eca348de7485990abfabdbc1086.camel@j-davis.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Mon, 2023-06-12 at 15:52 +0900, Michael Paquier wrote:
> 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.

Thank you, new patch attached.

I changed the Assert()s (the old ones as well as the ones I added) into
pg_log_warning()s. I don't think it makes sense to assert based on the
catalog contents in pg_dump -- other places just warn.

Also added a test.

> 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.

The new patch does add about 40 net lines, though.

Given that it fixes an obscure issue, I'm not even sure if it should be
backported -- perhaps it could just go in 17 as more of a cleanup than
a bugfix?

Even aside from the issue fixed by this patch, there are other warnings
emitted when dumping pg_catalog related to types with typtype='p' and
typisdefined=t.

Regards,
Jeff Davis

Attachment Content-Type Size
v2-0001-Fix-pg_dump-assertion-failure-when-dumping-pg_cat.patch text/x-patch 4.2 KB

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message David Rowley 2023-06-16 00:30:25 Re: BUG #17964: Missed query planner optimization
Previous Message Cory Albrecht 2023-06-15 21:11:05 Re: BUG #17977: PorstGreSQL in a jail crashes randomly with Signal 10 bus error