On Thu, Oct 6, 2011 at 2:26 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> On Thu, Oct 6, 2011 at 1:56 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >>> I'm inclined to think that the way to deal with that is not to force out >>> useless WAL data, but to add some sort of explicit "I'm alive" heartbeat >>> signal to the walsender/walreceiver protocol. The hard part of that is >>> to figure out how to expose it where you can see it on the slave side >>> --- or do we have a status view that could handle that? > >> As of 9.1, we already have something very much like this, in the >> opposite direction. See wal_receiver_status_interval and >> replication_timeout. I bet we could adapt that slightly to work in >> the other direction, too. But that'll only work with streaming >> replication - do we care about the WAL shipping case? > > I can't get excited about the WAL-shipping case. The artifact that we'll > generate a checkpoint record every few minutes does not create enough > WAL volume for WAL-shipping to reliably generate a heartbeat signal. > It'd be way too long between filling up segments if that were the only > WAL data being generated.
Depends how you set archive_timeout, I think. Anyway, I'm not saying we *have* to care about that case. I'm just asking whether we do, before we go start changing things. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
