Re: UPSERT strange behavior - Mailing list pgsql-hackers

From Tom Lane
Subject Re: UPSERT strange behavior
Date
Msg-id 20164.1472152606@sss.pgh.pa.us
Whole thread Raw
In response to Re: UPSERT strange behavior  (Peter Geoghegan <pg@heroku.com>)
Responses Re: UPSERT strange behavior  (Peter Geoghegan <pg@heroku.com>)
List pgsql-hackers
Peter Geoghegan <pg@heroku.com> writes:
> (I don't think that it matters which order anything is tested
> in, though, because not finding a dup value in the arbiter index does
> not guarantee that there won't be one in the other index. There is no
> locking when no conflict is initially found, and so no guarantees
> here.)

I'm not following.  The only insertions happening in this test case
are coming from various clients doing the same INSERT ON CONFLICT UPDATE.
If one of them has successfully inserted "42" into the arbiter index,
how is it that other ones are not seeing that?

> Anyway, I don't have a lot of sympathy for this point of view, because
> the scenario is completely contrived.

Well, I agree this particular test case looks contrived, but it might be
a simplification of a more convincing real-world case.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: UPSERT strange behavior
Next
From: Alvaro Herrera
Date:
Subject: Re: increasing the default WAL segment size