Re: strange error sequence on parallel btree creation

From: Peter Geoghegan <pg(at)bowt(dot)ie>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: Pg Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: strange error sequence on parallel btree creation
Date: 2019-01-30 17:24:10
Message-ID: CAH2-WzmWktge9+xRaO1VAcYBe+FDCPmL5eTQOu5K4w8OvwV07w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi Álvaro,

On Wed, Jan 30, 2019 at 5:40 AM Alvaro Herrera <alvherre(at)2ndquadrant(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Langote 2019-01-30 17:28:38 Re: speeding up planning with partitions
Previous Message Dmitry Dolgov 2019-01-30 17:19:05 Re: Index Skip Scan