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;
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
