On Wed, Feb 15, 2012 at 18:28, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
> On Wed, Feb 15, 2012 at 6:44 PM, Magnus Hagander <magnus(at)hagander(dot)net> wrote:
>> On Fri, Feb 10, 2012 at 04:34, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
>>> On Fri, Feb 10, 2012 at 8:14 AM, Magnus Hagander <magnus(at)hagander(dot)net> wrote:
>>>> On Thu, Feb 9, 2012 at 17:35, Heikki Linnakangas
>>>> <heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
>>>>> On 09.02.2012 15:14, Magnus Hagander wrote:
>>>>>> Have pg_receivexlog always send an invalid log position in status messages
>>>>>> This prevents pg_basebackup and pg_receivexlog from becoming a synchronous
>>>>>> standby in case 'write' is used for synchronous_commit.
>>>>> It's not completely crazy to use pg_receivexlog as a synchronous standby. It
>>>>> provides the zero-loss property like a real standby does, ie. if the master
>>>>> dies after sending the WAL to pg_receivexlog, that transaction is safe in
>>>>> the archive.
>>>> Yes, but as I stated in the email in the thread that the patch was
>>>> posted in, I think this should not be the default behaviour, but it
>>>> should be available as a commandline option, or something along that
>>> Even if we make that the default behavior, pg_receivexlog doesn't work as
>>> a sync standby unless synchronous_standby_names is set to "pg_receivexlog"
>>> or "*". There is little risk that we make that the default, I think... No?
>> We discussed this at some previous time, and since it's fairly common
>> for people to use "*" - in fact, I believe it's what most people do.
>> Which would lead to unintended consequences. I guess we could document
>> that very clearly in the docs of that parameter...
>>> Anyway, to consider pg_receivexlog as a sync standby, we need to change it
>>> so that its status report includes the valid write and flush
>>> positions, and so that
>>> it replies as soon as it writes or flushes the received WAL, like real
>>> sync standby
>>> does. Otherwise, the master has to wait for the status report interval (which is
>>> specified in -s or --statusint option of pg_receivexlog).
>> Yes, that's what I suggested be controled by a separate parameter.
>> Having it sync standby and only send status reports every now and then
>> seems like a really bad idea.
>>> The proposed change would increase the frequency for pg_receivexlog to send
>>> back the report very much. Which might be a problem. For people who want to
>>> avoid such frequent reports, we might need to introduce the option
>>> which specifies
>>> whether frequent report is allowed or not.
>> Exactly my point...
> Okay, barring objection, I will make the patch.
> But before making the patch, could you commit the patch which fix the incorrect
> handling of the timeout in pg_receivexlog? Or I should merge them into
> one patch?
(Sorry about the delays)
That one was sitting in my queue of "waiting for feedback". Did you
have a comment on the topic of backwards compatibility raised in that
thread? (and do comment in that thread in that case)
And I think we're better off keeping them as separate patches, if
nothing else that makes the reviews shorter :-)
In response to
pgsql-committers by date
|Next:||From: Simon Riggs||Date: 2012-02-22 13:54:39|
|Subject: pgsql: Correctly initialise shared recoveryLastRecPtr in recovery.|
|Previous:||From: User Jbcooley||Date: 2012-02-22 02:40:53|
|Subject: npgsql - Npgsql2: Updated to Npgsql 2.0.12 beta 3 (18.104.22.168) release.|