| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Peter Geoghegan <pg(at)heroku(dot)com> |
| Cc: | Ivan Frolkov <ifrol2001(at)mail(dot)ru>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: UPSERT strange behavior |
| Date: | 2016-08-25 19:16:46 |
| Message-ID: | 20164.1472152606@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Peter Geoghegan <pg(at)heroku(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alvaro Herrera | 2016-08-25 19:21:34 | Re: increasing the default WAL segment size |
| Previous Message | Peter Geoghegan | 2016-08-25 19:08:45 | Re: UPSERT strange behavior |