Re: Allow logical replication to copy tables in binary format - Mailing list pgsql-hackers

From Melih Mutlu
Subject Re: Allow logical replication to copy tables in binary format
Date
Msg-id CAGPVpCS0OzZ1tx3qT1Lc83HVK2JCc=TQ1G73tbyHYDKyo+mzFQ@mail.gmail.com
Whole thread Raw
In response to RE: Allow logical replication to copy tables in binary format  ("Takamichi Osumi (Fujitsu)" <osumi.takamichi@fujitsu.com>)
Responses Re: Allow logical replication to copy tables in binary format  (Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>)
List pgsql-hackers
Hi,

Thanks for your reviews.

Takamichi Osumi (Fujitsu) <osumi.takamichi@fujitsu.com>, 12 Oca 2023 Per, 06:07 tarihinde şunu yazdı:
On Wednesday, January 11, 2023 7:45 PM Melih Mutlu <m.melihmutlu@gmail.com> wrote:
(1-1) There is no need to log the version and the query by elog here.
(1-2) Also, I suggest we can remove the server_version variable itself,
      because we have only one actual reference for it.
      There is a style that we call walrcv_server_version in the
      'if condition' directly like existing codes in fetch_remote_table_info().
(1-3) Suggestion to improve comments.
      FROM:
      /* If the publisher is v16 or later, copy in binary format.*/
      TO:
      /* If the publisher is v16 or later, copy data in the required data format. */

Forgot to remove that LOG line. Removed it now and applied other suggestions too. 
 
I think if we change the order of this part of check like below, then
it would look more aligned with other existing test codes introduced by this patch.

Right. Changed it to make it more aligned with the rest.

Thanks, 
--
Melih Mutlu
Microsoft
Attachment

pgsql-hackers by date:

Previous
From: John Naylor
Date:
Subject: Re: [PoC] Improve dead tuple storage for lazy vacuum
Next
From: Kyotaro Horiguchi
Date:
Subject: Re: Lazy allocation of pages required for verifying FPI consistency