On Tue, Jun 5, 2012 at 10:44 AM, Magnus Hagander <magnus@hagander.net> wrote:
> On Tue, Jun 5, 2012 at 4:42 PM, Fujii Masao <masao.fujii@gmail.com> wrote:
>> On Tue, Jun 5, 2012 at 9:53 PM, Magnus Hagander <magnus@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