Re: Stefan's bug (was: max_standby_delay considered harmful)

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Stefan's bug (was: max_standby_delay considered harmful)
Дата
Msg-id AANLkTikNSTliNzAoObAR-cUflQHCGmVgjYFYfzyVdLP2@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Stefan's bug (was: max_standby_delay considered harmful)  (Simon Riggs <simon@2ndQuadrant.com>)
Ответы Re: Stefan's bug (was: max_standby_delay considered harmful)  (Fujii Masao <masao.fujii@gmail.com>)
Список pgsql-hackers
On Wed, May 19, 2010 at 8:49 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
> On Wed, 2010-05-19 at 08:21 -0400, Tom Lane wrote:
>> Robert Haas <robertmhaas@gmail.com> writes:
>> > On Wed, May 19, 2010 at 1:47 AM, Fujii Masao <masao.fujii@gmail.com> wrote:
>> >> Yes, but I prefer XLogCtl->SharedRecoveryInProgress, which is the almost
>> >> same indicator as the boolean you suggested. Thought?
>>
>> > It feels cleaner and simpler to me to use the information that the
>> > postmaster already collects rather than having it take locks and check
>> > shared memory, but I might be wrong.  Why do you prefer doing it that
>> > way?
>>
>> The postmaster must absolutely not take locks (once there are competing
>> processes).  This is non negotiable from a system robustness standpoint.
>
> Masao has not proposed this, in fact his proposal was to deliberately
> avoid do so.
>
> I proposed using the state recorded in xlog.c rather than attempting to
> duplicate that with a second boolean in postmaster because that seems
> likely to be more buggy.

Well then how are we reading XLogCtl?

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company


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

Предыдущее
От: Boszormenyi Zoltan
Дата:
Сообщение: Re: Synchronous replication patch built on SR
Следующее
От: Stefan Kaltenbrunner
Дата:
Сообщение: Re: BYTEA / DBD::Pg change in 9.0 beta