On Tue, Jun 5, 2012 at 11:44 PM, 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?
Yes. Currently the status update is sent for each status interval. In sync replication, transaction has to wait for a while even after pg_receivexlog has written or flushed the WAL data. So we should add new option which specifies whether pg_receivexlog sends the status packet back as soon as it writes or flushes the WAL data, like the walreceiver does? Regards, -- Fujii Masao -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
