From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
---|---|
To: | Peter Eisentraut <peter(at)eisentraut(dot)org>, 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-09-05 22:33:09 |
Message-ID: | c1037306f233c7705d00e05239d9c98a6bd62ad7.camel@j-davis.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Tue, 2023-09-05 at 11:45 +0200, Peter Eisentraut wrote:
> This new code replaces an (unexpected) null value with an empty
> string.
> Is that correct? Empty locale strings have specific behaviors under
> the
> libc and icu providers. It seems to me it would be better to error
> out
> or don't print a CREATE COLLATION command at all rather than
> substituting a value that is not a correct substitute.
It already issues a warning, which seemed more consistent with other
unexpected situations in pg_dump.
> Alternatively, a more correct way to produce a null value would be to
> not issue the assignment at all (omit the " lc_collation = " etc.).
> Then we can leave it up to the backend to accept the command or not,
> but
> at least the dump closely reflects the original catalog state.
The backend does not accept a collation specified with lc_ctype and not
lc_collate (or vice versa), so it would be an un-restorable dump. That
doesn't seem great.
Regards,
Jeff Davis
From | Date | Subject | |
---|---|---|---|
Next Message | James Pang (chaolpan) | 2023-09-06 01:40:56 | query pg_stat_ssl hang 100%cpu |
Previous Message | PG Bug reporting form | 2023-09-05 20:23:45 | BUG #18090: Encountering Toast Table Corruption and Missing Chunk Number Error During PostgreSQL Data Migration |