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

"Kevin Grittner" <Kevin.Grittner@wicourts.gov> writes:

> Dimitri Fontaine <dfontaine@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
(meanscurrent 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
beat 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