Re: Updated version of pg_receivexlog - Mailing list pgsql-hackers

From Magnus Hagander
Subject Re: Updated version of pg_receivexlog
Date
Msg-id CABUevEzbr7WY8+8Z4McE10ELYxkv15jJhha2iNoZLsaL30Drsg@mail.gmail.com
Whole thread Raw
In response to Updated version of pg_receivexlog  (Magnus Hagander <magnus@hagander.net>)
List pgsql-hackers
On Mon, Oct 24, 2011 at 16:12, Jaime Casanova <jaime@2ndquadrant.com> wrote:
> On Mon, Oct 24, 2011 at 7:40 AM, Magnus Hagander <magnus@hagander.net> wrote:
>>
>>> synchronous_standby_names='*' is prone to such confusion in general, but it
>>> seems that it's particularly surprising if a running pg_basebackup lets a
>>> commit in synchronous replication to proceed. Maybe we just need a warning
>>> in the docs. I think we should advise that synchronous_standby_names='*' is
>>> dangerous in general, and cite this as one reason for that.
>>
>> Hmm. i think this is common enough that we want to make sure we avoid
>> it in code.
>>
>> Could we pass a parameter from the client indicating to the master
>> that it refuses to be a sync slave? An optional keyword to the
>> START_REPLICATION command, perhaps?
>>
>
> can't you execute "set synchronous_commit to off/local" for this connection?

This is a walsender connection, it doesn't take SQL. Plus it's the
receiving end, and SET sync_commit is for the sending end.

that said, we are reasonably safe in current implementations, because
it always sets the flush location to invalidxlogptr, so it will not be
considered for sync slave. Should we ever start accepting "write" as
the point to sync against, the problem will show up, of course.

--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: termination of backend waiting for sync rep generates a junk log message
Next
From: Alexander Korotkov
Date:
Subject: Re: GiST for range types (was Re: Range Types - typo + NULL string constructor)