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 immediat
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-on
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 SERIA
> 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 fig
Josh Berkus 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 SSI patch will h
> 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.
--
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 vLo
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 alrea
