Re: Sync Rep v17

From: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, pgsql-hackers(at)postgresql(dot)org, Daniel Farina <daniel(at)heroku(dot)com>
Subject: Re: Sync Rep v17
Date: 2011-03-01 09:44:34
Message-ID: AANLkTinh_Yjgbxk6WPKjB_CJkMmwquF_=gCNL+Vp6D0Z@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Mar 1, 2011 at 4:56 PM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
>> > If allow_standalone_primary = on then we sit and wait until we hit
>> > client timeout, which occurs even after last standby has gone.
>>
>> In that case, why do backends need to wait until the timeout occurs?
>> We can make those backends resume their transaction as soon as
>> the last standby has gone. No?
>
> The guarantee provided is that we will wait for up to client timeout for
> the sync standby to confirm. If we stop waiting right at the point that
> an "event" occurs, it breaks the whole purpose of the feature.

ISTM that at least people (including me) who want to use synchronous
replication for high-availability don't like this behavior. Because, when
there is one synchronous standby and it's shut down, the transactions
would get blocked until the timeout happens. The system down time
gets longer.

Of course, if walsender doesn't detect the termination of replication
connection, I can't complain that transactions wait until the timeout
happens. But, otherwise, releasing the waiting transactions would
be help for high-availability, I think.

Regards,

--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Fujii Masao 2011-03-01 09:53:35 Re: Sync Rep v17
Previous Message Rumko 2011-03-01 09:21:10 Re: Porting PostgreSQL to DragonFly BSD