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

It seems to me that AccessShare(Exclusive)Lock is essentailly for
VACUUM. There's a possibilty to remove AccessExclusiveLock
except for VACUUM. Oracle has neither.
If AccessExclusiveLock is limited to VACUUM,AccessShareLock 
could be hold until end of transaction.

> 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.
In fact,I have already excluded LockPage() because it is not 
used for transaction control.

But I have thought that the main purpose of early release of lock
is to avoid long term lock for system tables. 
Have I misunderstood until now ?
> Can you give specific examples of cases that will be fixed?
>

Unfortunately no example now.
> For the most part I believe that we effectively protect updates to
> system-table rows by holding AccessExclusiveLock on the associated user

There are system-table rows which don't have the associated user relations
and there are many DDL commands except VACUUM.
We have to preserve consistency for system tuples among themselves,
don't we ?

> relation.  Locking the system table is just a means of preventing VACUUM
> from running concurrently on the system table (and possibly moving the
> tuple we want to update/delete).  So I think releasing the system-table
> lock is OK as long as we hold the user table lock till end of

This is needed for DDL command inside transactions,isn't it ?
But isn't walking on such a tightrope wasteful in order to realize DDL
command inside transactions either ?

Anyway,I want a decision here.
I have already done a wasteful work in current spec about "can neither
drop nor create" bug. 

Regards.

Hiroshi Inoue
Inoue@tpf.co.jp