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

From Andres Freund
Subject Re: [HACKERS] walsender & parallelism
Date
Msg-id 20170423234303.ljzdpcog2szyxbsm@alap3.anarazel.de
Whole thread Raw
In response to Re: [HACKERS] walsender & parallelism  (Petr Jelinek <petr.jelinek@2ndquadrant.com>)
Responses Re: [HACKERS] walsender & parallelism  (Petr Jelinek <petr.jelinek@2ndquadrant.com>)
List pgsql-hackers
On 2017-04-21 04:20:26 +0200, Petr Jelinek wrote:
> 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 think we really need to unify the paths between walsender and normal
backends to a much larger degree.


> 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)?

Historic raisins - there didn't use to be a SetLatch in
procsignal_sigusr1_handler. That changed when I whacked around catchup &
notify to be based on latches ([1] and following).

[1] https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=59f71a0d0b56b2df48db4bf1738aece5551f7a47

- Andres



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: [HACKERS] StandbyRecoverPreparedTransactions recovers subtranslinks incorrectly
Next
From: Noah Misch
Date:
Subject: Re: [HACKERS] pg_dump emits ALTER TABLE ONLY partitioned_table