Re: [Glue] [HACKERS] Deadlock bug

2010-08-24 Thread Kevin Grittner
Josh Berkus wrote: the behavior was the same up to the second UPDATE on Process 2, at which point there was no deadlock. Process 2 was able to commit, at which point Process 1 failed with: ERROR: could not serialize access due to concurrent update Does this happen immediately, not

Re: [Glue] [HACKERS] Deadlock bug

2010-08-23 Thread Josh Berkus
Kevin, In the for what it's worth department, I tried out the current Serializable Snapshot Isolation (SSI) patch with this test case at the SERIALIZABLE transaction isolation level. Rather than defining a foreign key, I ran the queries which an SSI implementation in a SERIALIZABLE-only

Re: [Glue] [HACKERS] Deadlock bug

2010-08-20 Thread Josh Berkus
On 8/20/10 7:18 AM, Tom Lane wrote: It does go through without any deadlock, *if* there is no foreign key involved. You didn't tell us exactly what the FK relationship is, but I suspect the reason for the deadlock is that one process is trying to update a row that references some row already

Re: [Glue] [HACKERS] Deadlock bug

2010-08-20 Thread Joel Jacobson
In my example, Process 1:Process 2: BEGIN; SELECT pg_backend_pid(); BEGIN; SELECT pg_backend_pid(); UPDATE A SET Col1 = 1 WHERE AID = 1; SELECT * FROM

Re: [Glue] [HACKERS] Deadlock bug

2010-08-20 Thread Josh Berkus
Another question, Tom referred to a comment in src/backend/command/trigger.c. My example does not contain any triggers, nor insert commands. Is the trigger.c-comment still relevant or is it a misunderstanding? It's relevant for how the FKs are handled. --

Re: [Glue] [HACKERS] Deadlock bug

2010-08-20 Thread Kevin Grittner
Josh Berkus j...@agliodbs.com wrote: That's correct. This is the generic example I was talking about earlier on -hackers. I'm not certain it's a bug per spec; I wanted to talk through with Kevin what we *should* be doing in this situation. I'm certainly happy to address what impact the

Re: [Glue] [HACKERS] Deadlock bug

2010-08-20 Thread Josh Berkus
In principle we don't need to sharelock the referencing row in either update in this example, since the original row version is still there. The problem is to know that, given the limited amount of information available when performing the second update. Ah, ok. I get it now. Now to figure

Re: [Glue] [HACKERS] Deadlock bug

2010-08-20 Thread Kevin Grittner
I wrote: If there are a lot of user-hostile behaviors there, it might be worth looking at the possibility of bending the SSI techniques to that end In the for what it's worth department, I tried out the current Serializable Snapshot Isolation (SSI) patch with this test case at the