Re: [HACKERS] walsender & parallelism

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: [HACKERS] walsender & parallelism
Дата
Msg-id 20170423234303.ljzdpcog2szyxbsm@alap3.anarazel.de
обсуждение исходный текст
Ответ на Re: [HACKERS] walsender & parallelism  (Petr Jelinek <petr.jelinek@2ndquadrant.com>)
Ответы Re: [HACKERS] walsender & parallelism
Список pgsql-hackers
On 2017-04-21 04:20:26 +0200, Petr Jelinek wrote:
> Looks like SIGUSR1 being different is problem here - it's normally used
> to . I also noticed that we don't handle SIGINT (query cancel).

I think we really need to unify the paths between walsender and normal
backends to a much larger degree.


> BTW while looking at the code, I don't understand why we call
> latch_sigusr1_handler after calling SetLatch(MyLatch), shouldn't just
> the SetLatch be enough (they both end up calling sendSelfPipeByte()
> eventually)?

Historic raisins - there didn't use to be a SetLatch in
procsignal_sigusr1_handler. That changed when I whacked around catchup &
notify to be based on latches ([1] and following).

[1] https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=59f71a0d0b56b2df48db4bf1738aece5551f7a47

- Andres



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

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: [HACKERS] StandbyRecoverPreparedTransactions recovers subtranslinks incorrectly
Следующее
От: Noah Misch
Дата:
Сообщение: Re: [HACKERS] pg_dump emits ALTER TABLE ONLY partitioned_table