Re: [HACKERS] walsender & parallelism
От | Petr Jelinek |
---|---|
Тема | Re: [HACKERS] walsender & parallelism |
Дата | |
Msg-id | 7966f454-7cd7-2b0c-8b70-cdca9d5a8c97@2ndquadrant.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] walsender & parallelism (Petr Jelinek <petr.jelinek@2ndquadrant.com>) |
Ответы |
Re: [HACKERS] walsender & parallelism
|
Список | pgsql-hackers |
On 21/04/17 04:37, Petr Jelinek wrote: > On 21/04/17 04:32, Craig Ringer wrote: >> On 21 April 2017 at 10:20, Petr Jelinek <petr.jelinek@2ndquadrant.com> wrote: >>> On 21/04/17 03:40, Andres Freund wrote: >>>> >>>> Since [1] walsender (not receiver as commit message says) can execute >>>> SQL queries. While doing some testing of [2] I noticed that SQL queries >>>> in walsender get stuck if parallelism is used - I have not investigated >>>> why that is yet, but it surely is an issue. On first blush I'd suspect >>>> that some signalling is not wired up correctly (cf. am_walsender branches >>>> in PostgresMain() and such). >>> >>> 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'll write proper patch but can you try to just use >>> procsignal_sigusr1_handler for SIGUSR1 in walsender.c to see if it fixes >>> the issue? >> >> That's what my recovery conflicts for logical decoding on standby >> patch does, FWIW. >> >> I haven't found any issues yet.. >> > > Ah I knew I've seen that change somewhere. I thought it was either in my > patch or master which is why I thought it's working fine already. > Here is patch. I changed both SIGINT and SIGUSR1 handlers, afaics it does not break anything for existing walsender usage. -- Petr Jelinek http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Вложения
В списке pgsql-hackers по дате отправления: