On Sat, Apr 21, 2012 at 2:25 AM, Eliot Gable
wrote:
> How do you control the order in which cascading deletes occur across tables
> and the order in which they fire the triggers which do the locking?
Well, I'd guess that they probably have a well-defined order. However...
> Within a single funct
On Fri, Apr 20, 2012 at 11:25 AM, Eliot Gable
wrote:
> On Fri, Apr 20, 2012 at 11:46 AM, Chris Angelico wrote:
>>
>>
>> You have a Dining Philosophers Problem. Why can you not control the
>> order in which they acquire their locks? That's one of the simplest
>> solutions - for instance, all updat
On Fri, Apr 20, 2012 at 11:46 AM, Chris Angelico wrote:
>
> You have a Dining Philosophers Problem. Why can you not control the
> order in which they acquire their locks? That's one of the simplest
> solutions - for instance, all update locks are to be acquired in
> alphabetical order of table na
On Sat, Apr 21, 2012 at 1:27 AM, Eliot Gable
wrote:
> If I use pg_advisory_lock(), can I lock and unlock a table multiple times in
> both transactions without ever needing to worry about them getting
> deadlocked on rows? Doing select locks on rows is not an option because they
> last until the en
On Fri, Apr 20, 2012 at 10:27 AM, Eliot Gable
wrote:
> Is it possible to prevent row deadlocks by using pg_advisory_lock()? For
> example:
>
> Transaction 1 grabs pg_advisory_lock(1)
> Transaction 1 runs a statement that updates multiple rows on Table A
> Transaction 1 releases pg_advisory_lock(1)
Is it possible to prevent row deadlocks by using pg_advisory_lock()? For
example:
Transaction 1 grabs pg_advisory_lock(1)
Transaction 1 runs a statement that updates multiple rows on Table A
Transaction 1 releases pg_advisory_lock(1)
Transaction 1 continues processing other stuff
Transaction 1 gra
