Re: [COMMITTERS] pgsql: Fix planner crash from pfree'ing a partial path that a GatherPat

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [COMMITTERS] pgsql: Fix planner crash from pfree'ing a partial path that a GatherPat
Date: 2016-05-02 12:59:58
Message-ID: CA+TgmoaNNE7XWASd3UPm9ZCTvo=W9Er0PWVSDXYNWf57_CrkMg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

On Sat, Apr 30, 2016 at 12:29 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Fix planner crash from pfree'ing a partial path that a GatherPath uses.
>
> We mustn't run generate_gather_paths() during add_paths_to_joinrel(),
> because that function can be invoked multiple times for the same target
> joinrel. Not only is it wasteful to build GatherPaths repeatedly, but
> a later add_partial_path() could delete the partial path that a previously
> created GatherPath depends on. Instead establish the convention that we
> do generate_gather_paths() for a rel only just before set_cheapest().
>
> The code was accidentally not broken for baserels, because as of today there
> never is more than one partial path for a baserel. But that assumption
> obviously has a pretty short half-life, so move the generate_gather_paths()
> calls for those cases as well.
>
> Also add some generic comments explaining how and why this all works.
>
> Per fuzz testing by Andreas Seltenreich.
>
> Report: <871t5pgwdt(dot)fsf(at)credativ(dot)de>

Thanks!

The preposition at the end of this sentence broke my internal English parser:

+ * This must not be called until after we're done creating all partial paths
+ * for the specified relation. (Otherwise, add_partial_path might delete a
+ * path that some GatherPath has a reference to.)

I eventually figured out what you were saying there, and it does make sense.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Browse pgsql-committers by date

  From Date Subject
Next Message Robert Haas 2016-05-02 13:03:19 Re: Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold <
Previous Message Heikki Linnakangas 2016-05-02 07:19:21 pgsql: Remove unused macros.

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2016-05-02 13:03:19 Re: Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold <
Previous Message Robert Haas 2016-05-02 12:53:21 Re: WIP: Covering + unique indexes.