From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Thomas Swan <tswan(at)idigx(dot)com> |
Cc: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: SELECT FOR UPDATE |
Date: | 2003-07-25 13:10:51 |
Message-ID: | 7869.1059138651@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Thomas Swan <tswan(at)idigx(dot)com> writes:
> Hypothetically, if I knew the relations that contained the tuples I was
> locking, I could conceivably visit them in, let's say, alphabetical
> order or oid order or any predictable order, and then select the rows
> for update (using oid order or primary key order). It would be hard to
> induce a deadlock condition if the locks being acquired where in a
> consistently reproducible order by all processes.
Given that this requires programmer discipline anyway, I think it's okay
to leave the whole thing in the hands of the programmer. My original
comment that the locks are acquired in an unpredictable order wasn't
right --- they are acquired by the executor's top level, therefore
in the order the rows come out of the execution engine, and therefore
you can make the order predictable if you want to. Just use ORDER BY.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Shridhar Daithankar | 2003-07-25 14:03:26 | Re: hardware performance and some more |
Previous Message | Andrew Sullivan | 2003-07-25 12:21:58 | Re: php with postgres |