On Tue, Jun 5, 2012 at 4:42 PM, Fujii Masao <masao.fu...@gmail.com> wrote: > On Tue, Jun 5, 2012 at 9:53 PM, Magnus Hagander <mag...@hagander.net> wrote: >> Right now, pg_receivexlog sets: >> replymsg->write = InvalidXLogRecPtr; >> replymsg->flush = InvalidXLogRecPtr; >> replymsg->apply = InvalidXLogRecPtr; >> >> when it sends it's status updates. >> >> I'm thinking it sohuld set replymsg->write = blockpos instad. >> >> Why? That way you can see in pg_stat_replication what has actually >> been received by pg_receivexlog - not just what we last sent. This can >> be useful in combination with an archive_command that can block WAL >> recycling until it has been saved to the standby. And it would be >> useful as a general monitoring thing as well. >> >> I think the original reason was that it shouldn't interefer with >> synchronous replication - but it does take away a fairly useful >> usecase... > > I think that not only replaymsg->write but also ->flush should be set to > blockpos in pg_receivexlog. Which allows pg_receivexlog to behave > as synchronous standby, so we can write WAL to both local and remote > synchronously. I believe there are some use cases for synchronous > pg_receivexlog.
pg_receivexlog doesn't currently fsync() after every write. It only fsync():s complete files. So we'd need to set ->flush only at the end of a segment, right? > OTOH, neither replaymsg->write nor ->flush should be set to > InvalidXLogRecPtr, to prevent pg_basebackup from behaving as > synchronous standby. Oh, good point. So yeah, we'd need to make it a parameter to the function. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
