Re: SegFault on 9.6.14

From: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
To: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
Cc: Jerry Sievers <gsievers19(at)comcast(dot)net>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com>
Subject: Re: SegFault on 9.6.14
Date: 2019-07-18 09:40:32
Message-ID: CA+hUKGJ6GU37i46BUp69-zxHmNnG66SQXLv9oewLLufDZtaGfw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Jul 18, 2019 at 6:40 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> On Wed, Jul 17, 2019 at 4:10 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> > Yeah, that is a problem. Actually, what we need here is to
> > wait-for-workers-to-finish and collect all the instrumentation
> > information. We don't need to destroy the shared memory at this
> > stage, but we don't have a special purpose function which can just
> > allow us to collect stats. One idea could be that we create a special
> > purpose function which sounds like a recipe of code duplication,
> > another could be that somehow pass the information through
> > ExecShutdownNode to Gather/GatherMerge that they don't destroy shared
> > memory. Immediately, I can't think of better ideas, but it is
> > possible that there is some better way to deal with this.
>
> I am not able to come up with anything better. Robert, Thomas, do you
> see any problem with this idea or do you have any better ideas to fix
> this issue?

Hmm, so something like a new argument "bool final" added to the
ExecXXXShutdown() functions, which receives false in this case to tell
it that there could be a rescan so keep the parallel context around.
Or alternatively a separate function with another end-of-scan type of
name that I'm having trouble inventing, which is basically the same
but a bigger patch. If you add a new argument you might in theory
want to pass that on to the ShutdownForeignScan and ShutdownCustomScan
callbacks, but we obviously can't change those APIs in the back
branches. If you add a new function instead you might theoretically
want to add it to those APIs too, which you also can't really do in
the back branches either (well even if you could, existing extensions
won't register anything). I think the new argument version is
probably better because I suspect only Gather would really ever have
any reason to treat the two cases differently, and all existing cases
in or out of core would just keep doing what they're doing. So I
think adding "bool final" (or better name) would probably work out OK,
and I don't have a better idea.

--
Thomas Munro
https://enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Paul Guo 2019-07-18 10:30:13 Re: Possible race condition in pg_mkdir_p()?
Previous Message Жарков Роман 2019-07-18 09:14:34 Re: Intermittent pg_ctl failures on Windows