From: | gkokolatos(at)pm(dot)me |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | Justin Pryzby <pryzby(at)telsasoft(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org, Rachel Heaton <rachelmheaton(at)gmail(dot)com> |
Subject: | Re: Add LZ4 compression in pg_dump |
Date: | 2023-01-16 15:14:43 |
Message-ID: | twKgLFeqHEshCjdrbnzkwTMHiqfqvrrPSni7eKZjcxkForO-sI7HL4AKFgk9En1nGk3i4TXOY_An2xnCzv8MNjoLz4iupACaRB-0VRV20V4=@pm.me |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
I admit I am completely at lost as to what is expected from me anymore.
I had posted v19-0001 for a committer's consideration and v19-000{2,3} for completeness.
Please find a rebased v20 attached.
Also please let me know if I should silently step away from it and let other people lead
it. I would be glad to comply either way.
Cheers,
//Georgios
------- Original Message -------
On Monday, January 16th, 2023 at 3:54 AM, Michael Paquier <michael(at)paquier(dot)xyz> wrote:
>
>
> On Sun, Jan 15, 2023 at 07:56:25PM -0600, Justin Pryzby wrote:
>
> > On Mon, Jan 16, 2023 at 10:28:50AM +0900, Michael Paquier wrote:
> >
> > > The functions changed by 0001 are cfopen_write,
> > > AllocateCompressor() and ReadDataFromArchive(). Why is it a good idea
> > > to change these interfaces which basically exist to handle inputs?
> >
> > I changed to pass pg_compress_specification as a pointer, since that's
> > the usual convention for structs, as followed by the existing uses of
> > pg_compress_specification.
>
>
> Okay, but what do we gain here? It seems to me that this introduces
> the risk that a careless change in one of the internal routines if
> they change slight;ly compress_spec, hence impacting any of their
> callers? Or is that fixing an actual bug (except if I am missing your
> point, that does not seem to be the case)?
>
> > > Is there some benefit in changing compression_spec within the
> > > internals of these routines before going back one layer down to their
> > > callers? Changing the compression_spec on-the-fly in these internal
> > > paths could be risky, actually, no?
> >
> > I think what you're saying is that if the spec is passed as a pointer,
> > then the called functions shouldn't set spec->algorithm=something.
>
>
> Yes. HEAD makes sure of that, 0001 would not prevent that. So I am a
> bit confused in seeing how this is a benefit.
> --
> Michael
Attachment | Content-Type | Size |
---|---|---|
v20-0001-Prepare-pg_dump-internals-for-additional-compres.patch | text/x-patch | 21.9 KB |
v20-0003-THIS-IS-WIP-PATCH-PRESENTED-HERE-FOR-COMPLETENES.patch | text/x-patch | 29.0 KB |
v20-0002-THIS-IS-WIP-PATCH-PRESENTED-HERE-FOR-COMPLETENES.patch | text/x-patch | 65.5 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2023-01-16 15:19:49 | Re: macOS versioned sysroot |
Previous Message | Joe Conway | 2023-01-16 14:58:12 | Re: [PATCH] Add <<none>> support to sepgsql_restorecon |