From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Magnus Hagander <magnus(at)hagander(dot)net> |
Cc: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pg_receivexlog and feedback message |
Date: | 2012-06-06 18:52:09 |
Message-ID: | CA+TgmoYWOV_TYqYWcaFWkt9D_2bqpAFN7_EmzN4-ghD24TpJqw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Jun 5, 2012 at 10:44 AM, Magnus Hagander <magnus(at)hagander(dot)net> wrote:
> On Tue, Jun 5, 2012 at 4:42 PM, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
>> On Tue, Jun 5, 2012 at 9:53 PM, Magnus Hagander <magnus(at)hagander(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Ants Aasma | 2012-06-06 18:54:15 | Re: 9.2beta1, parallel queries, ReleasePredicateLocks, CheckForSerializableConflictIn in the oprofile |
Previous Message | Robert Haas | 2012-06-06 18:45:46 | Re: \conninfo and SSL |