Re: strange error sequence on parallel btree creation - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: strange error sequence on parallel btree creation
Date
Msg-id CAH2-WzmWktge9+xRaO1VAcYBe+FDCPmL5eTQOu5K4w8OvwV07w@mail.gmail.com
Whole thread Raw
In response to strange error sequence on parallel btree creation  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-hackers
Hi Álvaro,

On Wed, Jan 30, 2019 at 5:40 AM Alvaro Herrera <alvherre@2ndquadrant.com> wrote:
> Note that those come from the same create index: the one on process
> 46299 must evidently be a parallel worker.  It's weird that two
> processes report the index building error.  But even if it were correct,
> the CONTEXT line in the other process is not okay ... precisely because
> it's the parent.
>
> What I did was
>
> create table a as select * from generate_series(1, 1000000);
> insert into a select * from generate_series(1, 80000000);
> create index on a (generate_series);

I can see why you'd find that slightly confusing. I'm not sure what
can be done about this scenario specifically, though. It seems to come
down to how the parallel infrastructure works, which is not something
that I gave much input on.

Fundamentally, the parallel infrastructure wants to propagate all
errors that it received before parallel workers were shut down. I
think that that's probably the right thing to do. I'm not sure what
you mean by "But even if it were correct, the CONTEXT line in the
other process is not okay ... precisely because it's the parent".
Perhaps you can go into more detail on that. The CONTEXT looks like it
would look regardless of this race.

In any case, I think that the chances of this happening in production
are pretty slim. The error messages each refer to specific, distinct
pairs of duplicates (duplicated values). It's probably necessary to
have an enormous number of duplicates for things to work out this way.
That's hardly typical.

--
Peter Geoghegan


pgsql-hackers by date:

Previous
From: Dmitry Dolgov
Date:
Subject: Re: Index Skip Scan
Next
From: Amit Langote
Date:
Subject: Re: speeding up planning with partitions