Re: walsender & parallelism

From: Andres Freund <andres(at)anarazel(dot)de>
To: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
Cc: Petr Jelinek <petr(dot)jelinek(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: walsender & parallelism
Date: 2017-06-02 03:03:26
Message-ID: 20170602030326.al7fzcievk5ujz6m@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Langote 2017-06-02 04:51:35 Re: BEFORE trigger can cause undetected partition constraint violation
Previous Message Stephen Frost 2017-06-02 02:23:11 Re: Patch: Add --no-comments to skip COMMENTs with pg_dump