On Tue, Jun 5, 2012 at 10:44 AM, Magnus Hagander <mag...@hagander.net> wrote: > 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?
If you want to be able to use it as a synchronous standby, that's not going to work very well. You could end up with pg_receivexlog waiting for the end of the segment before it flushes; meanwhile, all the clients are sitting there waiting for the flush to happen before they do anything that could generate more WAL to fill the segment. Unless you have a solution to that problem, I'd recommend setting write (which should work with the new remote_write mode for sync rep) but not setting flush. -- 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
