Re: [ADMIN] pg_basebackup blocking all queries with horrible performance

Поиск
Список
Период
Сортировка
От Fujii Masao
Тема Re: [ADMIN] pg_basebackup blocking all queries with horrible performance
Дата
Msg-id CAHGQGwEPBrECq9ht1MnEYPK5Bpy4ozv1VYyLO6LJY_6OFi2SYQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [ADMIN] pg_basebackup blocking all queries with horrible performance  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: [ADMIN] pg_basebackup blocking all queries with horrible performance  (Simon Riggs <simon@2ndQuadrant.com>)
Re: [ADMIN] pg_basebackup blocking all queries with horrible performance  (Magnus Hagander <magnus@hagander.net>)
Список pgsql-hackers
On Thu, Jun 21, 2012 at 3:18 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Wed, Jun 20, 2012 at 7:18 AM, Magnus Hagander <magnus@hagander.net> wrote:
>>>>> You agreed to add something like NOSYNC option into START_REPLICATION command?
>>>>
>>>> I'm on the fence. I was hoping somebody else would chime in with an
>>>> opinion as well.
>>>
>>> +1
>>
>> Nobody else with any opinion on this? :(
>
> I don't think we really need a NOSYNC flag at this point.  Just not
> setting the flush location in clients that make a point of flushing in
> a timely fashion seems fine.

Okay, I'm in the minority, so I'm writing the patch that way. WIP
patch attached.

In the patch, pg_basebackup background process and pg_receivexlog always
return invalid location as flush one, and will never become sync standby even
if their name is in synchronous_standby_names. The timing of their sending
the reply depends on the standby_message_timeout specified in -s option. So
the write position may lag behind the true position.

pg_receivexlog accepts new option -S (better option character?). If this option
is specified, pg_receivexlog returns true flush position, and can become sync
standby. It sends back the reply to the master each time the write position
changes or the timeout passes. If synchronous_commit is set to remote_write,
synchronous replication to pg_receivexlog would work well.

The patch needs more documentation. But I think that it's worth reviewing the
code in advance, so I attached the WIP patch. Comments? Objections?

The patch is based on current HEAD, i.e., 9.3dev. If the patch is applied,
we need to write the backport version of the patch for 9.2.

Regards,

--
Fujii Masao

Вложения

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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Regarding WAL Format Changes
Следующее
От: Fujii Masao
Дата:
Сообщение: Re: Regarding WAL Format Changes