From: | Craig Ringer <craig(at)2ndquadrant(dot)com> |
---|---|
To: | Petr Jelinek <petr(dot)jelinek(at)2ndquadrant(dot)com> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Petr Jelinek <petr(at)2ndquadrant(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net> |
Subject: | Re: walsender & parallelism |
Date: | 2017-04-21 02:32:02 |
Message-ID: | CAMsr+YGAKGcAVpEB7Br3yS9GNdB-KEF0LJEpHPiyf7XFnBr2PQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 21 April 2017 at 10:20, Petr Jelinek <petr(dot)jelinek(at)2ndquadrant(dot)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..
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Petr Jelinek | 2017-04-21 02:34:40 | Re: DROP SUBSCRIPTION, query cancellations and slot handling |
Previous Message | Noah Misch | 2017-04-21 02:24:12 | Re: tablesync patch broke the assumption that logical rep depends on? |