Re: SELECT FOR UPDATE

From: Thomas Swan <tswan(at)idigx(dot)com>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: SELECT FOR UPDATE
Date: 2003-07-25 01:39:03
Message-ID: 3F208A37.7010806@idigx.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Bruce Momjian wrote:

>Thomas Swan wrote:
>
>
>>When a SELECT FOR UPDATE query is executed, are the row level locks on a
>>table acquired in any specific order such as to enhance deadlock
>>prevention? ( primary key, oid, etc. )
>>
>>
>
>Interesting question, because in a join, you could have multiple tables
>involved. Sorry, I don't know the answer.
>
>
>
I had remembered several readings on ordered locking as a method to
prevent deadlocks, and associated that with select for update
methodology. In theory if you aquired locks in the following order, for
each table/relation (in oid order) get rows/tuples (in oid order), you
could help avoid deadlock by never gaining a lock ahead of someone
else. Locks could be released in the same order. The system should be
predictable even with oid wrap arounds.

I'm quite sure that someone has done something like this for postgres
though....

Perhaps table/row oids are a good idea?

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2003-07-25 01:42:59 name of configure threading option
Previous Message Bruce Momjian 2003-07-25 01:23:25 Re: SELECT FOR UPDATE