Re: Sync Rep: First Thoughts on Code

Поиск
Список
Период
Сортировка
От Fujii Masao
Тема Re: Sync Rep: First Thoughts on Code
Дата
Msg-id 3f0b79eb0812151936y5d4ab129i96794a62f58e95ab@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Sync Rep: First Thoughts on Code  (Simon Riggs <simon@2ndQuadrant.com>)
Ответы Re: Sync Rep: First Thoughts on Code  (Simon Riggs <simon@2ndQuadrant.com>)
Список pgsql-hackers
Hi,

Sorry for this late reply. And, thanks for the hot discussion ;)

On Tue, Dec 16, 2008 at 1:24 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
>
> Fujii-san,
>
> Just repeating this in case you lost this comment:
>
> On Mon, 2008-12-15 at 09:40 +0000, Simon Riggs wrote:
>
>> Fujii-san, please can we incorporate those two options, rather than just
>> one choice "synchronous_replication = on". They look like two commonly
>> requested options.
>
> I see the comment in line 230+ of walreceiver.c, so understand that you
> have implemented option #3 from the following list.
>
> So from my previous list
>
> 1. We sent the message to standby (A)
> 2. We received the message on standby
> 3. We wrote the WAL to the WAL file (B)
> 4. We fsync'd the WAL file (C)
> 5. We CRC checked the WAL commit record
> 6. We applied the WAL commit record
>
> Please could you also add an option #4, i.e. add the *option* to fsync
> the WAL to disk at commit time also. That requires us to add a third
> option to synchronous_replication parameter.

The above option should be configured on the primary? or standby?
The primary is suitable to vary it from transaction to transaction. On
the other hand, it should be configured on the standby in order to
choose it for every standby (in the future).

I prefer the latter, and thought that it should be added into recovery.conf.
I mean, synchronous_replication identifies only whether commit waits for
replication (if the name is confusing, I would rename it). The above
options (#1-#6) are chosen in recovery.conf. What is your opion?

>> #6 is an additional synchronization step in Hot Standby. I would say
>> that people won't want that when they see how it performs (they probably
>> won't want #4 either for that same reason, but that is for robustness).
>
> We can jointly add option #6 once we have both sync rep and hot standby
> committed, or at a late stage of hot standby development. There's not
> much point looking at it before then.

Agreed.

Regards,

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


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

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: DROP ROLE dependency tracking ...
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: Mostly Harmless: Welcoming our C++ friends