Horton

Re: Binary support for pgoutput plugin

Dave Cramer <davecramer@gmail.com>

View thread View on postgr.es
From: Dave Cramer <davecramer@gmail.com>
To: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: Dmitry Dolgov <9erthalion6@gmail.com>, Thomas Munro <thomas.munro@gmail.com>, Tomas Vondra <tomas.vondra@2ndquadrant.com>, Petr Jelinek <petr.jelinek@2ndquadrant.com>, Andres Freund <andres@anarazel.de>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2019-11-11T19:42:30Z
Lists: pgsql-hackers

Attachments

On Mon, 11 Nov 2019 at 12:07, Dave Cramer <davecramer@gmail.com> wrote:

>
>
> On Mon, 11 Nov 2019 at 12:04, Alvaro Herrera <alvherre@2ndquadrant.com>
> wrote:
>
>> On 2019-Nov-11, Dave Cramer wrote:
>>
>> > Previously someone mentioned that we need to confirm whether the two
>> > servers are compatible for binary or not.
>> >
>> > Checking to make sure the two servers have the same endianness is
>> obvious.
>> > Sizeof int, long, float, double, timestamp (float/int) at a minimum.
>> >
>> > this could be done in libpqrcv_startstreaming. The question I have
>> > remaining is do we fall back to text mode if needed or simply fail ?
>>
>> I think it makes more sense to have it fail.  If the user wants to retry
>> in text mode, they can do that easily enough; but if we make it
>> fall-back automatically and they set up the received wrongly by mistake,
>> they would pay the performance penalty without noticing.
>>
>>
> Alvaro,
>
> thanks, after sending this I pretty much came to the same conclusion.
>
> Dave
>

Following 2 patches address Dmitry's concern and check for compatibility.

Commits

  1. Weaken type-OID-matching checks in array_recv and record_recv.

  2. Fix construction of updated-columns bitmap in logical replication.

  3. Allow logical replication to transfer data in binary format.

  4. Phase 2 pgindent run for v12.