Josh Berkus wrote:
> So, here's a must-fix item for SR for release: we need adequate docs.
> I'm happy to write these but *I* need to understand the answers first.
Many thanks!
> The current docs and wiki page do not explain:
>
> * How (technically) the slave listens for LSNs
Hmm, not sure what you mean. In a nutshell, the slave connects to the
master over a libpq connection, and master sends the logs as they are
generated.
> * Does the walreceiver need the archive (via archive_command) copies of
> the WAL files after it's caught up with the master?
No. But if the the connection is lost and standby falls behind enough
that the logs are deleted in the master already, it will need the
archive to catch up again.
> ** If so, can we somehow use pg_standby with SR?
No. pg_standby would do the waiting, and the streaming would never start.
I've been wondering if we should actually deprecate pg_standby in favor
of having the startup process do the retrying. So you would configure
restore_command to use 'cp' as in normal archive recovery, and the
server would retry running it every few seconds. It seems we're going to
need that retry logic in the slave anyway, to catch up automatically
after a lost connection. Once it's in there, you could use it without
streaming replication just as well.
> I've tried to dig this information out of the wiki and mailing list
> archives and can't quite figure it out. Is there a tech doc which was
> not posted anywhere public, or do I need to just RTFC?
Feel free to ask.
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com