|To:||Michael Paquier <michael(at)paquier(dot)xyz>|
|Cc:||Robert Haas <robertmhaas(at)gmail(dot)com>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Jeevan Ladhe <jeevan(dot)ladhe(at)enterprisedb(dot)com>|
|Subject:||Re: Refactoring of compression options in pg_basebackup|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
On Wednesday, January 5th, 2022 at 9:00 AM, Michael Paquier <michael(at)paquier(dot)xyz> wrote:
> On Mon, Jan 03, 2022 at 03:35:57PM +0000, gkokolatos(at)pm(dot)me wrote:
> > I propose to initialize streamer to NULL when declared at the top of
> > CreateBackupStreamer().
> Yes, that may be noisy. Done this way.
> > You can see that after the check_pg_config() test, only 3 tests follow,
> > namely:
> > * $node->command_ok()
> > * is(scalar(), ...)
> > * is($gzip_is_valid, ...)
> Indeed. The CF bot was complaining about that, actually.
> Thinking more about this stuff, pg_basebackup --compress is an option
> that exists already for a couple of years, and that's independent of
> the backend-side compression that Robert and Jeevan are working on, so
> I'd like to move on this code cleanup. We can always figure out the
> LZ4 part for pg_basebackup after, if necessary.
I agree that the cleanup in itself is helpful. It feels awkward to have two
utilities under the same path, with distinct options for the same
When the backend-side compression is completed, were there really be a need for
client-side compression? If yes, then it seems logical to have distinct options
for them and this cleanup makes sense. If not, then it seems logical to maintain
the current options list and 'simply' change the internals of the code, and this
cleanup makes sense.
> Attached is an updated patch. The CF bot should improve with that.
|Next Message||tushar||2022-01-05 10:11:38||Re: refactoring basebackup.c|
|Previous Message||Amit Kapila||2022-01-05 09:15:47||Re: row filtering for logical replication|