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?
> 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/
