Re: Comments to Synchronous replication patch v3

Поиск
Список
Период
Сортировка
От Fujii Masao
Тема Re: Comments to Synchronous replication patch v3
Дата
Msg-id 3f0b79eb0811301817u7fafdffbx387fa5b27b838f92@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Comments to Synchronous replication patch v3  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Hi, thanks for the comment!

On Sat, Nov 29, 2008 at 1:10 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> "Fujii Masao" <masao.fujii@gmail.com> writes:
>>>> You export replication_timeout as a PGC_USERSET variable, but it is
>>>> dangerous. It allows non-superusers to kill servers easily by setting it
>>>> too low value. Walsender dies with FATAL on timeout.
>
>> Unlike other background processes, FATAL by walsender doesn't kill the
>> whole server. In FATAL case, walsender is treated like the normal backend,
>> and only walsender dies. Please see reaper() in postmaster.c.
>
>> Just to be safe, I re-export the parameter as PGC_SUSET in the latest
>> patch. Is still this parameter dangerous?
>
> If this parameter is only used by a background process, then both of
> those are wrong.  It should be marked SIGHUP to reflect the fact that
> the only effective way of modifying it is via postgresql.conf.

This parameter is used by the backend to wait for replication to complete
for the specified time at most. If the timeout has come, the backend send
the timtout-interrupt to walsender. Then walsender invokes FATAL error,
which doesn't kill the whole server. So, I choosed PGC_USERSET at first.

Regards,

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


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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Problem in contrib/tablefunc's crosstab()
Следующее
От: Greg Smith
Дата:
Сообщение: Re: Simple postgresql.conf wizard