Re: Re: Synch Rep: direct transfer of WAL file from the primary to the standby

"Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> writes:

> Dimitri Fontaine <dfontaine(at)hi-media(dot)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