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

From Petr Jelinek
Subject Re: [HACKERS] walsender & parallelism
Date
Msg-id e41081d2-080f-b612-2084-549fa652fae2@2ndquadrant.com
Whole thread Raw
In response to [HACKERS] walsender & parallelism  (Andres Freund <andres@anarazel.de>)
Responses Re: [HACKERS] walsender & parallelism  (Craig Ringer <craig@2ndquadrant.com>)
Re: [HACKERS] walsender & parallelism  (Andres Freund <andres@anarazel.de>)
List 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 by date:

Previous
From: Stephen Frost
Date:
Subject: Re: [HACKERS] pg_dump emits ALTER TABLE ONLY partitioned_table
Next
From: Noah Misch
Date:
Subject: Re: [HACKERS] tablesync patch broke the assumption that logical repdepends on?