On Thu, Aug 25, 2016 at 12:16 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > 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?
It's complicated. One backend may completely overtake another in this race. We don't give up early within ExecInsertIndexTuples(), because there isn't any useful distinction made between the speculative insertion case, and the deferred constraint case. The ordering, as such, is therefore irrelevant. Fortunately, I posted a fix, of sorts, more than a year ago: https://commitfest.postgresql.org/10/403/ It never occurred to me to make this argument for it. There is a separate question of how to make the ordering avoid problems if it did matter (if that patch ever got committed). I think it would fix this exact test case, but only accidentally, because the executor gets a list of IndexInfo structs from the relcache in a consistent though fairly insignificant order (ordered by OID). I don't think you can change that property within the relcache, because the ordering must be consistent (to avoid deadlocks, perhaps elsewhere). Maybe we should change the ordering of those IndexInfo structs to something more suitable, but it must be immutable (it cannot hinge upon the details of one particular DML statement). I actually also wrote a patch to prefer insertion into the primary key first, which also went nowhere (I gave up on that one, to be fair). -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers