From: | Justin Pryzby <pryzby(at)telsasoft(dot)com> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Simplifications for error messages related to compression |
Date: | 2022-12-21 02:29:32 |
Message-ID: | 20221221022931.GK1153@telsasoft.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Dec 21, 2022 at 10:43:19AM +0900, Michael Paquier wrote:
> On Mon, Dec 19, 2022 at 02:42:13PM +0900, Michael Paquier wrote:
> > Thoughts or objections?
>
> Hearing nothing, done..
- pg_fatal("not built with zlib support");
+ pg_fatal("this build does not support compression with %s", "gzip");
I tried to say in the other thread that gzip != zlib.
This message may be better for translation, but (for WriteDataToArchive
et al) the message is now less accurate, and I suspect will cause some
confusion.
5e73a6048 introduced a similar user-facing issue: pg_dump -Fc -Z gzip
does not output a gzip.
$ ./tmp_install/usr/local/pgsql/bin/pg_dump -h /tmp -Fc -Z gzip regression |xxd |head
00000000: 5047 444d 5001 0e00 0408 0101 0100 0000 PGDMP...........
I'm okay with it if you think this is no problem - maybe it's enough to
document that the output is zlib and not gzip.
Otherwise, one idea was to reject "gzip" with -Fc. It could accept
integers only.
BTW I think it's helpful to include the existing participants when
forking a thread.
--
Justin
From | Date | Subject | |
---|---|---|---|
Next Message | Amin | 2022-12-21 02:34:32 | Get access to the whole query in CustomScan path callback |
Previous Message | Peter Smith | 2022-12-21 02:01:41 | Re: Perform streaming logical transactions by background workers and parallel apply |