On Wed, Feb 8, 2012 at 19:39, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
> On Tue, Oct 25, 2011 at 7:37 PM, Magnus Hagander <magnus(at)hagander(dot)net> wrote:
>> On Mon, Oct 24, 2011 at 14:40, Magnus Hagander <magnus(at)hagander(dot)net> wrote:
>>> On Mon, Oct 24, 2011 at 13:46, Heikki Linnakangas
>>> <heikki(dot)linnakangas(at)enterprisedb(dot)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.
> 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.
In response to
pgsql-hackers by date
|Next:||From: Alvaro Herrera||Date: 2012-02-09 13:45:45|
|Subject: Re: [COMMITTERS] pgsql: Add new keywords SNAPSHOT and TYPES to the keyword list in gram.|
|Previous:||From: Noah Misch||Date: 2012-02-09 12:24:49|
|Subject: Re: Progress on fast path sorting, btree index creation time|