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
