Re: pgsql: Have pg_receivexlog always send an invalid log position in statu

Поиск
Список
Период
Сортировка
От Fujii Masao
Тема Re: pgsql: Have pg_receivexlog always send an invalid log position in statu
Дата
Msg-id CAHGQGwG-YxfPsMXwkjC6BEtYehjktRTMWp6NWJ8M26mZCf0O7A@mail.gmail.com
обсуждение исходный текст
Ответ на Re: pgsql: Have pg_receivexlog always send an invalid log position in statu  (Magnus Hagander <magnus@hagander.net>)
Ответы Re: pgsql: Have pg_receivexlog always send an invalid log position in statu  (Magnus Hagander <magnus@hagander.net>)
Список pgsql-committers
On Wed, Feb 15, 2012 at 6:44 PM, Magnus Hagander <magnus@hagander.net> wrote:
> On Fri, Feb 10, 2012 at 04:34, Fujii Masao <masao.fujii@gmail.com> wrote:
>> On Fri, Feb 10, 2012 at 8:14 AM, Magnus Hagander <magnus@hagander.net> wrote:
>>> On Thu, Feb 9, 2012 at 17:35, Heikki Linnakangas
>>> <heikki.linnakangas@enterprisedb.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
>>> line.
>>
>> 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?
http://archives.postgresql.org/pgsql-hackers/2012-02/msg00257.php

Regards,

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

В списке pgsql-committers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: pgsql: Speed up in-memory tuplesorting.
Следующее
От: Robert Haas
Дата:
Сообщение: pgsql: sepgsql: Move some code from hooks.c to label.c