RE: [HACKERS] Re: [GENERAL] drop/rename table and transactions

> > -----Original Message-----
> > From: owner-pgsql-hackers(at)postgresql(dot)org
> > [mailto:owner-pgsql-hackers(at)postgresql(dot)org]On Behalf Of Tom Lane
> >
> > "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)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 command properly 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 till end 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 acquiring AccessExcl-
usiveLock.

6) commands/commands.c(ALTER TABLE)
ALTER TABLE doesn't release AccessExclusiveLock till
end of transaction. I couldn't find 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 concrete flaw now.

Regards.

Hiroshi Inoue
Inoue(at)tpf(dot)co(dot)jp