RE: [HACKERS] Re: [GENERAL] drop/rename table and transactions - Mailing list pgsql-hackers

> > -----Original Message-----
> > From: owner-pgsql-hackers@postgresql.org
> > [mailto:owner-pgsql-hackers@postgresql.org]On Behalf Of Tom Lane
> >
> > "Hiroshi Inoue" <Inoue@tpf.co.jp> writes:
> > >> I propose here that we stop the release of lock before end of
> > transaction.
> > >> I have been suffering from the early release of lock.
> >
> > > If there's no objection,I would change UnlockRelation() to
> not release
> > > the specified lock except AccessShareLock.
> >
> > After thinking about this some more, I am not convinced that it will buy
> > anything --- and it might possibly break things that work now.  The
> > reason I'm not convinced about it is that we cannot apply the "don't
> > release locks till end of transaction" rule perfectly uniformly.  You
>
> Why are we allowed to break 2 phase locking for system tables ?
> Isn't 2 phase locking a fundamental principle to preserve consistency ?
> If there's another principle to rely on,please teach me.
>
> > already propose not to treat AccessShareLock that way, and Vadim seems
> > to think there will be other cases where we need to break the rule.
> > So we won't have a theoretically-clean situation anyway, and will have
> > to look at things case by case.
> >
>
> OK case by case. I will be glad to check them one by one.

I'm checking them for AccessExclusiveLock now.

As for RowExclusiveLock,it would be much effective to remove
the release of lock unconditionally.
RowExclusiveLock isn't so intensive a lock. For example it
doesn't conflict relatively.  Therefore it would be hard to find
and resolve the bugs which are caused by the early release
of RowExclusiveLock,deadlock etc ...
Holding the lock a little longer won't be so harmful inversely.

Comments ?

As for AccessExclusiveLock I found followings now.

1) commands/user.c(CREATE/DROP/ALTER USER)   I could create same 2 users easily.   The lock should be held till end of
trancaction.

2) commands/cluster.c(CLUSTER)   It isn't properly implemented. It seems almost impossible   to implement CLUSTER
commandproperly in current spec.
 

3) commands/dbcommands.c(DROP DATABASE)   elog(ERROR) follows immediately. The release should   be removed.

4) commands/sequence.c(CREATE SEQUNECE)   The lock is for the being created (sequence) relation.   Holding the lock
tillend of transaction has no problem.
 

5) commands/vacuum.c(VACUUM)   The release is caused by new security check. Probably   the check could be done before
acquiringAccessExcl-   usiveLock.
 

6) commands/commands.c(ALTER TABLE)   ALTER TABLE doesn't release AccessExclusiveLock till   end of transaction.  I
couldn'tfind any reason to allow   the release for inheritors of a relation class. The release   should be removed.
 

7) commands/async.c(LISTEN/UNLISTEN)   This case seems dangerous too but unfortunately I couldn't   point out a
concreteflaw now.
 

Regards.

Hiroshi Inoue
Inoue@tpf.co.jp