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

From Peter Smith
Subject Re: Allow logical replication to copy tables in binary format
Date
Msg-id CAHut+Pubvnb3vD1W7ZpRHzjoQgusr2TZp4diPuJ7tJBmELNzQw@mail.gmail.com
Whole thread Raw
In response to Re: Allow logical replication to copy tables in binary format  (Melih Mutlu <m.melihmutlu@gmail.com>)
Responses Re: Allow logical replication to copy tables in binary format  (Amit Kapila <amit.kapila16@gmail.com>)
List pgsql-hackers
There are a couple of TAP tests where the copy binary is expected to
fail. And when it fails, you do binary=false (changing the format back
to 'text') so the test is then expected to be able to proceed.

I don't know if this happens in practice, but IIUC in theory, if the
timing is extremely bad, the tablesync could relaunch in binary mode
multiple times (any fail multiple times?) before your binary=false
change takes effect.

So, I was wondering if it could help to use the subscription
'disable_on_error=true' parameter for those cases so that the
tablesync won't needlessly attempt to relaunch until you have set
binary=false and then re-enabled the subscription.

------
Kind Regards,
Peter Smith.
Fujitsu Australia



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Fix fseek() detection of unseekable files on WIN32
Next
From: Thomas Munro
Date:
Subject: Re: Commitfest 2023-03 starting tomorrow!