public inbox for [email protected]
help / color / mirror / Atom feedRe: Add LZ4 compression in pg_dump
2+ messages / 2 participants
[nested] [flat]
* Re: Add LZ4 compression in pg_dump
@ 2023-03-01 17:08 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 2+ messages in thread
From: Justin Pryzby @ 2023-03-01 17:08 UTC (permalink / raw)
To: [email protected]; +Cc: Tomas Vondra <[email protected]>; [email protected]; Michael Paquier <[email protected]>; [email protected]; Rachel Heaton <[email protected]>
On Wed, Mar 01, 2023 at 01:39:14PM +0000, [email protected] wrote:
> On Wednesday, March 1st, 2023 at 12:58 AM, Justin Pryzby <[email protected]> wrote:
>
> > The current function order avoids 3 lines of declarations, but it's
> > obviously pretty useful to be able to run that diff command. I already
> > argued for not calling the functions "Gzip" on the grounds that the name
> > was inaccurate.
>
> I have no idea why we are back on the naming issue. I stand by the name
> because in my humble opinion helps the code reader. There is a certain
> uniformity when the compression_spec.algorithm and the compressor
> functions match as the following code sample shows.
I mentioned that it's because this allows usefully running "diff"
against the previous commits.
> if (compression_spec.algorithm == PG_COMPRESSION_NONE)
> InitCompressorNone(cs, compression_spec);
> else if (compression_spec.algorithm == PG_COMPRESSION_GZIP)
> InitCompressorGzip(cs, compression_spec);
> else if (compression_spec.algorithm == PG_COMPRESSION_LZ4)
> InitCompressorLZ4(cs, compression_spec);
>
> When the reader wants to see what happens when the PG_COMPRESSION_XXX
> is set, has to simply search for the XXX part. I think that this is
> justification enough for the use of the names.
You're right about that.
But (with the exception of InitCompressorGzip), I'm referring to the
naming of internal functions, static to gzip.c, so renaming can't be
said to cause a loss of clarity.
> > I'd want to create an empty large object in src/test/sql/largeobject.sql
> > to exercise this tested during pgupgrade. But unfortunately that
> > doesn't use -Fc, so this isn't hit. Empty input is an important enough
> > test case to justify a tap test, if there's no better way.
>
> Please find in the attached a test case that exercises this codepath.
Thanks for writing it.
This patch could be an opportunity to improve the "diff" output, without
renaming anything.
The old order of functions was:
-InitCompressorZlib
-EndCompressorZlib
-DeflateCompressorZlib
-WriteDataToArchiveZlib
-ReadDataFromArchiveZlib
If you put DeflateCompressorEnd immediately after DeflateCompressorInit,
diff works nicely. You'll have to add at least one declaration, which
seems very worth it.
--
Justin
^ permalink raw reply [nested|flat] 2+ messages in thread
* Re: [PATCH] Fix null pointer dereference in PG19
@ 2026-07-10 08:42 Peter Eisentraut <[email protected]>
0 siblings, 0 replies; 2+ messages in thread
From: Peter Eisentraut @ 2026-07-10 08:42 UTC (permalink / raw)
To: Paul A Jungwirth <[email protected]>; +Cc: Tom Lane <[email protected]>; Aleksander Alekseev <[email protected]>; pgsql-hackers
On 09.07.26 17:22, Paul A Jungwirth wrote:
> Checking at v1 is Aleksander's original patch. Then v2 adds tests that
> crash the server. v3 moves the check to rewrite time, and the tests
> pass. v4 moves the check again to exec time. But v4 is a behavior
> change: an UPDATE that touches zero rows no longer fails. I thought
> that was weird; that's why I recommended leaving it out (in
> https://www.postgresql.org/message-id/
> CA%2BrenyXPEJYOVov3XtzTp3NusGkObc9UeW-Nm78K8_nsWSnnfg%40mail.gmail.com
> before I added the crashing tests).
I committed patches 0001 through 0003 (squashed).
I think I was mistaken about the need for an executor check (patch
0004). But we can add it on if a need appears.
^ permalink raw reply [nested|flat] 2+ messages in thread
end of thread, other threads:[~2026-07-10 08:42 UTC | newest]
Thread overview: 2+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2023-03-01 17:08 Re: Add LZ4 compression in pg_dump Justin Pryzby <[email protected]>
2026-07-10 08:42 Re: [PATCH] Fix null pointer dereference in PG19 Peter Eisentraut <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox