Re: [HACKERS] walsender & parallelism
От | Petr Jelinek |
---|---|
Тема | Re: [HACKERS] walsender & parallelism |
Дата | |
Msg-id | e41081d2-080f-b612-2084-549fa652fae2@2ndquadrant.com обсуждение исходный текст |
Ответ на | [HACKERS] walsender & parallelism (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: [HACKERS] walsender & parallelism
Re: [HACKERS] walsender & parallelism |
Список | pgsql-hackers |
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? 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)? -- Petr Jelinek http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: