[HACKERS] Re: Problems with approach #2 to value locking (INSERT ... ON CONFLICT UPDATE/IGNORE patch)

2015-02-02 Thread Heikki Linnakangas
On 01/03/2015 10:42 PM, Peter Geoghegan wrote: On Sat, Jan 3, 2015 at 2:41 AM, Heikki Linnakangas wrote: A-ha, I see. And this can happen without INSERT ON CONFLICT, too? In that case, one of the transactions is bound to error and roll back anyway, but you get a deadlock error instead of the co

[HACKERS] Re: Problems with approach #2 to value locking (INSERT ... ON CONFLICT UPDATE/IGNORE patch)

2015-01-05 Thread Peter Geoghegan
On Mon, Jan 5, 2015 at 5:53 PM, Peter Geoghegan wrote: > It's not all that easy to recreate, even with my custom > instrumentation. With fsync=off, it occurs somewhat infrequently with > a custom instrumentation Postgres build: > > pg@hamster:~/jjanes_upsert$ perl count_upsert.pl 8 10 > [Mon J

[HACKERS] Re: Problems with approach #2 to value locking (INSERT ... ON CONFLICT UPDATE/IGNORE patch)

2015-01-05 Thread Peter Geoghegan
On Thu, Jan 1, 2015 at 11:17 PM, Peter Geoghegan wrote: > The attached patch fixes Jeff's test case, as far as it goes. But, as > I mentioned, it's not intended as a real fix. For one thing, I have > made multiple changes to HeapTupleSatisfies*() routines, but haven't > fully considered the conseq

[HACKERS] Re: Problems with approach #2 to value locking (INSERT ... ON CONFLICT UPDATE/IGNORE patch)

2015-01-04 Thread Peter Geoghegan
On Sat, Jan 3, 2015 at 10:16 PM, Peter Geoghegan wrote: > I looked at the code in more detail, and realized that there were old > bugs in the exclusion constraint related modifications. I attach a > delta patch that fixes them. This is a combined patch that is all that > is needed to apply on top

[HACKERS] Re: Problems with approach #2 to value locking (INSERT ... ON CONFLICT UPDATE/IGNORE patch)

2015-01-03 Thread Peter Geoghegan
On Sat, Jan 3, 2015 at 12:42 PM, Peter Geoghegan wrote: > There are probably additional factors that make the situation more > complicated than it is for the ON CONFLICT patch, but it's clear to me > that the mutual dependency that can be involved with two ordinary > exclusion constraint inserters

[HACKERS] Re: Problems with approach #2 to value locking (INSERT ... ON CONFLICT UPDATE/IGNORE patch)

2015-01-03 Thread Peter Geoghegan
On Sat, Jan 3, 2015 at 2:41 AM, Heikki Linnakangas wrote: > A-ha, I see. And this can happen without INSERT ON CONFLICT, too? In that > case, one of the transactions is bound to error and roll back anyway, but > you get a deadlock error instead of the constraint violation error, which is > not as

[HACKERS] Re: Problems with approach #2 to value locking (INSERT ... ON CONFLICT UPDATE/IGNORE patch)

2015-01-03 Thread Heikki Linnakangas
On 01/03/2015 12:00 PM, Peter Geoghegan wrote: Two concurrent exclusion constraints inserters can easily insert at exactly the same time, and then wait on each other's xact, and then deadlock. That can't happen with B-Tree inserts because the checking and insertion happen at the same time, when t

[HACKERS] Re: Problems with approach #2 to value locking (INSERT ... ON CONFLICT UPDATE/IGNORE patch)

2015-01-03 Thread Peter Geoghegan
On Sat, Jan 3, 2015 at 1:29 AM, Heikki Linnakangas wrote: > Please explain in words of one syllable how the deadlock arises. Then, > please find a way to fix it. I believe that the deadlock arises because there is no choke point. Exclusion constraint insertions always insert first, then check for

[HACKERS] Re: Problems with approach #2 to value locking (INSERT ... ON CONFLICT UPDATE/IGNORE patch)

2015-01-03 Thread Heikki Linnakangas
On 01/03/2015 02:43 AM, Peter Geoghegan wrote: On Thu, Jan 1, 2015 at 11:17 PM, Peter Geoghegan wrote: I've been working on fixing the bugs that Jeff Janes found [1] with approach #2 to value locking [2]. Approach #1 was unaffected. Unfortunately, exclusion constraints (which only value locki

[HACKERS] Re: Problems with approach #2 to value locking (INSERT ... ON CONFLICT UPDATE/IGNORE patch)

2015-01-02 Thread Peter Geoghegan
On Thu, Jan 1, 2015 at 11:17 PM, Peter Geoghegan wrote: > I've been working on fixing the bugs that Jeff Janes found [1] with > approach #2 to value locking [2]. Approach #1 was unaffected. Unfortunately, exclusion constraints (which only value locking approach #2 has support for, for the IGNORE