On Wed, Feb 8, 2012 at 19:39, Fujii Masao <masao.fujii@gmail.com> wrote:
> On Tue, Oct 25, 2011 at 7:37 PM, Magnus Hagander <magnus@hagander.net> wrote:
>> On Mon, Oct 24, 2011 at 14:40, Magnus Hagander <magnus@hagander.net> wrote:
>>> On Mon, Oct 24, 2011 at 13:46, Heikki Linnakangas
>>> <heikki.linnakangas@enterprisedb.com> wrote:
>>>> How does this interact with synchronous replication? If a base backup that
>>>> streams WAL is in progress, and you have synchronous_standby_names set to
>>>> '*', I believe the in-progress backup will count as a standby for that
>>>> purpose. That might give a false sense of security.
>>>
>>> Ah yes. Did not think of that. Yes, it will have this problem.
>>
>> Actually, thinking more, per other mail, it won't. Because it will
>> never report that the data is synced to disk, so it will not be
>> considered for sync standby.
>
> Now, new replication mode (synchronous_commit = write) is supported.
> In this mode, the in-progress backup will be considered as sync
> standby because its periodic status report includes the valid write position.
> We should change the report so that it includes only invalid positions.
> Patch attached.
Agreed, applied.
> While I agree that the backup should not behave as sync standby, ISTM
> that pg_receivexlog should, which is very useful. If pg_receivexlog does
> so, we can write WAL synchronously in both local and remote, which
> would increase the durability of the system. Thus, to allow pg_receivexlog
> to behave as sync standby, we should change it so that its status report
> includes the write and flush positions?
Yes, that could be useful. I don't think it should do so by default,
though, but it could be useful to provide a commandline switc hto
pg_receivexlog allowing it to do this.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/