Re: Built-in plugin for logical decoding output

From: Andres Freund <andres(at)anarazel(dot)de>
To: Gregory Brail <gregbrail(at)google(dot)com>
Cc: Alvaro Hernandez <aht(at)ongres(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Built-in plugin for logical decoding output
Date: 2017-09-23 01:28:46
Message-ID: 20170923012846.zwyseenigco56p3q@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 2017-09-22 17:11:47 -0700, Gregory Brail wrote:
> Also in lieu of the new snapshot mechanism for logical replication, which
> might not work for us

This needs context...

>, we were using the transaction ID to calculate what
> was committed in a client's snapshot and what they need to apply to their
> own local database. That relied on the transaction ID, and we wanted to use
> a 64-bit ID so that we could handle rollover. We ended up doing this:
>
> https://github.com/apigee-labs/transicator/blob/2d5dc596a5f2f5e13967e0f1943f248d88eac1e7/pgoutput/transicator_output.c#L151
>
> It looks to me like the new stuff only puts a 32-bit "xid" in there. Would
> there be a way to include the epoch as well? (And yes, I realize it might
> require a more detailed explanation which I'm happy to put together.)

It'd be good to see some more detail here, indeed. Especially if you
could look at what pgoutput provides, and whether that's sufficient.
I'm not entirely sure how much we want to make pgoutput configurable, in
contrast to adding something that's intended to be very configurable at
the price of some performance and bandwidth...

Regards,

Andres

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2017-09-23 01:53:02 Re: CREATE COLLATION does not sanitize ICU's BCP 47 language tags. Should it?
Previous Message Andrew Dunstan 2017-09-23 01:27:29 Re: BUG #14825: enum type: unsafe use?