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;