Re: [HACKERS] Built-in plugin for logical decoding output - Mailing list pgsql-hackers

From Andres Freund
Subject Re: [HACKERS] Built-in plugin for logical decoding output
Date
Msg-id 20170923012846.zwyseenigco56p3q@alap3.anarazel.de
Whole thread Raw
In response to Re: [HACKERS] Built-in plugin for logical decoding output  (Gregory Brail <gregbrail@google.com>)
List 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


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: [HACKERS] [BUGS] BUG #14825: enum type: unsafe use?
Next
From: Peter Geoghegan
Date:
Subject: Re: [HACKERS] CREATE COLLATION does not sanitize ICU's BCP 47language tags. Should it?