Re: [HACKERS] UPSERT strange behavior

2016-08-25 Thread Peter Geoghegan
On Thu, Aug 25, 2016 at 12:59 PM, Peter Geoghegan wrote: > 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 meant that it must be stable

Re: [HACKERS] UPSERT strange behavior

2016-08-25 Thread Peter Geoghegan
On Thu, Aug 25, 2016 at 12:16 PM, Tom Lane 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

Re: [HACKERS] UPSERT strange behavior

2016-08-25 Thread Konstantin Knizhnik
On 08/25/2016 10:08 PM, Peter Geoghegan wrote: On Thu, Aug 25, 2016 at 11:49 AM, Tom Lane wrote: I think the point is that given the way he's set up the test case, there should be no duplicate violation in the plain unique index unless there is one in the arbiter index. So

Re: [HACKERS] UPSERT strange behavior

2016-08-25 Thread Tom Lane
Peter Geoghegan 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,

Re: [HACKERS] UPSERT strange behavior

2016-08-25 Thread Peter Geoghegan
On Thu, Aug 25, 2016 at 11:49 AM, Tom Lane wrote: > I think the point is that given the way he's set up the test case, > there should be no duplicate violation in the plain unique index > unless there is one in the arbiter index. So assuming that INSERT > tests the arbiter

Re: [HACKERS] UPSERT strange behavior

2016-08-25 Thread Tom Lane
Peter Geoghegan writes: > On Thu, Aug 25, 2016 at 7:12 AM, Ivan Frolkov wrote: >> So, if we have primary key and unique constraint on a table then upsert will >> not work as would expected. > Why is this unexpected? > You only take the alternative path

Re: [HACKERS] UPSERT strange behavior

2016-08-25 Thread Peter Geoghegan
On Thu, Aug 25, 2016 at 7:12 AM, Ivan Frolkov wrote: > So, if we have primary key and unique constraint on a table then upsert will > not work as would expected. Why is this unexpected? You only take the alternative path (UPDATE) in the event of a would-be duplicate

[HACKERS] UPSERT strange behavior

2016-08-25 Thread Ivan Frolkov
Suppose we have some table create table cnt(  usr_id int primary key,  usr_doc_ref text not null,  cnt int,  sum int ); And going to run some insert on conflict update on it (pgbench script): \setrandom id 1 50 insert into cnt as c(usr_id,usr_doc_ref, cnt) values(:id, '#'||:id, 1) on