"Kevin Grittner" <kevin.gritt...@wicourts.gov> writes: > Dimitri Fontaine <dfonta...@hi-media.com> wrote: > >> 4. sync: slave is no more lagging, it's applying the stream as it >> gets it, either as part of the master transaction or not >> depending on the GUC settings > > I think the interesting bit is when you're at this point and the > connection between the master and slave goes down for a couple days. > How do you handle that?
Maybe how londiste handle the case could help us here: http://skytools.projects.postgresql.org/doc/londiste.ref.html#toc18 State | Owner | What is done ---------------------+--------+-------------------- NULL | replay | Changes state to "in-copy", launches londiste.py copy process, continues with it's work in-copy | copy | drops indexes, truncates, copies data in, restores indexes, changes state to "catching-up" catching-up | copy | replay events for that table only until no more batches (means current moment), change state to "wanna-sync:<tick_id>" and wait for state to change wanna-sync:<tick_id> | replay | catch up to given tick_id, change state to "do-sync:<tick_id>" and wait for state to change do-sync:<tick_id> | copy | catch up to given tick_id, both replay and copy must now be at same position. change state to "ok" and exit ok | replay | synced table, events can be applied Such state changes must guarantee that any process can die at any time and by just restarting it can continue where it left. "subscriber add" registers table with NULL state. "subscriber add —expect-sync" registers table with ok state. "subscriber resync" sets table state to NULL. Regards, -- dim -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
