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

From Andres Freund
Subject Re: [HACKERS] walsender & parallelism
Date
Msg-id 20170602030326.al7fzcievk5ujz6m@alap3.anarazel.de
Whole thread Raw
In response to Re: [HACKERS] walsender & parallelism  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
List pgsql-hackers
On 2017-06-01 22:17:57 -0400, Peter Eisentraut wrote:
> On 6/1/17 00:06, Andres Freund wrote:
> > On 2017-05-31 23:51:08 -0400, Peter Eisentraut wrote:
> >> I think the easiest and safest thing to do now is to just prevent
> >> parallel plans in the walsender.  See attached patch.  This prevents the
> >> hang in the select_parallel tests run under your new test setup.
> > I'm not quite sure I can buy this.  The lack of wired up signals has
> > more problems than just hurting parallelism.
> 
> Which problems are those?

For example not wiring up sigusr1, which is the cause of the paralellism
hang, breaks several things including recovery conflict interrupts.
Which means HS standby is affected. Just forbidding parallelism doesn't
address this.

> I can see from the code what they might be,
> but which ones actually happen in practice?  And are there any
> regressions from 9.6?

Yes. For example the issue that atm walsender backends don't ever quit
when executing sql statements is new.

> If someone wants to work all this out, that would be great.  But I'm
> here mainly to fix the one reported problem.

I'll deal with the issues in this thread.

- Andres



pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: [HACKERS] Patch: Add --no-comments to skip COMMENTs with pg_dump
Next
From: Amit Langote
Date:
Subject: Re: [HACKERS] BEFORE trigger can cause undetected partitionconstraint violation