Re: WAL fsync scheduling

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: WAL fsync scheduling
Дата
Msg-id 5936.974575264@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: WAL fsync scheduling  (Peter Eisentraut <peter_e@gmx.net>)
Список pgsql-hackers
Peter Eisentraut <peter_e@gmx.net> writes:
>> Now all you need is a free signal number. Unfortunately we're already
>> using both SIGUSR1 and SIGUSR2.

> Maybe you could dump the old meaning SIGQUIT (externally invoked error),
> move quickdie() to SIGQUIT, and you got SIGUSR1 free.

> (That would even make sense in two ways:  1) SIGQUIT would actually cause
> the guy to quit; 2) there is a correspondence between postmaster and
> postgres signals.)

Seems like a plan.  The current definition of backend SIGQUIT is really
stupid anyway --- what's the value of forcing an error asynchronously?

Also, it always bothered me that the postmaster and backend signals
weren't consistent, so I'd be inclined to make this change even if we
end up not using SIGUSR1 for Bruce's idea ...
        regards, tom lane


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

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Re: Re: BIT/BIT VARYING status
Следующее
От: devik@cdi.cz
Дата:
Сообщение: Re: RE: [COMMITTERS] pgsql/src/backend/access/transam (xact.c xlog.c)