On Thu, Aug 11, 2022, at 8:04 AM, Amit Kapila wrote:
On Thu, Aug 11, 2022 at 7:34 AM Euler Taveira <euler@eulerto.com> wrote:
>
> The reason to use text format is that it is error prone. There are restrictions
> while using the binary format. For example, if your schema has different data
> types for a certain column, the copy will fail.
>
Won't such restrictions hold true even during replication?
I expect that the COPY code matches the proto.c code. The point is that table
sync is decoupled from the logical replication. Hence, we should emphasize in
the documentation that the restrictions *also* apply to the initial table
synchronization.
If such restrictions are already the case for replication phase after initial table sync, then it shouldn't prevent us from enabling binary option for table sync. Right?
* Are we considering to support prior Postgres versions too? These releases
support binary mode but it could be an unexpected behavior (initial sync in
binary mode) for a publisher using 14 or 15 and a subscriber using 16. IMO
you should only allow it for publisher on 16 or later.
How is any issue that might occur due to version mismatch being handled right now in repliaction after table sync?
What I understand from the documentation is if replication can fail due to using different pg versions, it just fails. So binary option cannot be used. [1]
Do you think that this is more serious for table sync and we need to restrict binary option with different publisher and subscriber versions? But not for replication?
* Docs should say that the binary option also applies to initial table
synchronization and possibly emphasize some of the restrictions.
* Tests. Are the current tests enough? 014_binary.pl.
You're right on both points. I just wanted to know your opinions on this first. Then the patch will need some tests and proper documentation.
