[Bizgres-general] Another use case

[Jim C. Nasby]

On Fri, Aug 11, 2006 at 04:47:22PM +1000, Gavin Sherry wrote:
> On Fri, 11 Aug 2006, Mark Kirkwood wrote:
> 
> > Mark Kirkwood wrote:
> > >
> > > Hmm , Yeah - good scenario. We might be ok if it is only the
> > > [Row]Exclusive locks on the target relation that I'm dropping - as there
> > > will still be AccessShare ones on all the relations in the query - which
> > > should prevent the DROP COLUMN or similar from beginning.
> > >
> > >
> >
> > Actually Gavin is correct, we have to be a bit more subtle than that -
> > merely dropping the [Row]ExclusiveLock could leave the target relation
> > without any lock at all. However, I think taking an AccessShareLock and
> > *then* dropping the [Row]ExclusiveLock should work as intended.
> 
> I wonder if there's a deadlock condition where you could have two queries
> where query 1 is being demoted from RowExclusive to AccessShare and query
> 2 is being promoted from AccessShare to RowExclusive...
> 
> Actually, it doesn't seem like there is because query 1 will definately
> get the AccessShare lock. However, take a good look at some of the
> comments in LockAcquire/Release because lock demotion is not something the
> code currently expects to happen, it seems.
 
I think it's probably OK to allow for dropping the locks and then
re-aquiring them when it's time to actually run, and letting the user or
the backend deal with any problems that arise from DDL. That's probably
the best compromise. Maybe there should be an option to DDL that would
force queued statements to drop their locks?

> > A quick piece of hackery to test this idea seemed to leave locks as
> > indicated. - we can no doubt discuss this sort of thing in more detail
> > next week when I'm at Greenplum (assuming planes from here to US don't
> > get grounded.... ).
> 
> Hmm... I recommend you ring your airline if you plan to take your laptop
> with you. Lots of talk on the news today about not being able to take
> laptops aboard US bound planes :-(.

Only applies to carry-on, AFAIK. Still sucks. :(
-- 
Jim C. Nasby, Sr. Engineering Consultant      jnasby at pervasive.com
Pervasive Software      http://pervasive.com    work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf       cell: 512-569-9461