Re: Allow logical replication to copy tables in binary format

Euler Taveira <euler@eulerto.com>

From: "Euler Taveira" <euler@eulerto.com>

To: "Amit Kapila" <amit.kapila16@gmail.com>

Cc: "Melih Mutlu" <m.melihmutlu@gmail.com>, pgsql-hackers <pgsql-hackers@postgresql.org>

Date: 2022-08-11T13:26:40Z

Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

Allow logical replication to copy tables in binary format.
- ecb696527c01 16.0 landed
Common function for percent placeholder replacement
- c96de2ce1782 16.0 cited
Doc: add XML ID attributes to <sectN> and <varlistentry> tags.
- 78ee60ed84bb 16.0 cited
Re-order disable_on_error in tab-complete.
- d547f7cf5efc 16.0 cited
Make subscription tests pass with log_error_verbosity=verbose
- 19408aae7fa2 15.0 cited
Weaken type-OID-matching checks in array_recv and record_recv.
- 670c0a1d474b 14.0 cited
Allow logical replication to transfer data in binary format.
- 9de77b545313 14.0 cited

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.


--
Euler Taveira
EDB   https://www.enterprisedb.com/