Re: logical changeset generation v6.1

On 10/07/2013 09:32 AM, Andres Freund wrote:
> Todo:
> * rename treat_as_catalog_table, after agreeing on the new name
> * rename remaining timetravel function names
> * restrict SuspendDecodingSnapshots usage to RelationInitPhysicalAddr,
> that ought to be enough.
> * add InLogicalDecoding() function.
> * throw away older data when reading xl_running_xacts records, to deal
> with immediate shutdowns/crashes

What is your current plan for decoding sequence updates? Is this
something that you were going to hold-off on supporting till a future
version? ( know this was discussed a while ago but I don't remember
where it stands now)

From a Slony point of view this isn't a big deal, I can continue to
capture sequence changes in sl_seqlog when I create each SYNC event and
then just replicate the INSERT statements in sl_seqlog via logical
decoding. I can see why someone building a replication system not based
on the concept of a SYNC would have a harder time with this.

I am guessing we would want to pass sequence operations to the plugins
as we encounter the WAL for them out-of-band of any transaction. This
would mean that a set of operations like

begin;
insert into a (id) values(4);
insert into a (id) values(nextval('some_seq'));
commit

would be replayed on the replicas as
setval('some_seq',100);
begin;
insert into a (id) values (4);
insert into a (id) values (100);
commit;