Re: [HACKERS] walsender & parallelism - Mailing list pgsql-hackers

From Petr Jelinek
Subject Re: [HACKERS] walsender & parallelism
Date
Msg-id a6167509-dc9f-411b-3bbd-758ab8079139@2ndquadrant.com
Whole thread Raw
In response to Re: [HACKERS] walsender & parallelism  (Craig Ringer <craig@2ndquadrant.com>)
Responses Re: [HACKERS] walsender & parallelism  (Petr Jelinek <petr.jelinek@2ndquadrant.com>)
List pgsql-hackers
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.

--  Petr Jelinek                  http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training &
Services



pgsql-hackers by date:

Previous
From: Petr Jelinek
Date:
Subject: Re: [HACKERS] DROP SUBSCRIPTION, query cancellations and slothandling
Next
From: Masahiko Sawada
Date:
Subject: Re: [HACKERS] Interval for launching the table sync worker