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-11T17:07:20Z
Lists: pgsql-hackers 
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

>
>

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.