From: | "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "Vadim Mikheev" <vadim(at)krs(dot)ru>, "PostgreSQL Developers List" <hackers(at)postgresql(dot)org> |
Subject: | RE: [HACKERS] Re: [GENERAL] drop/rename table and transactions |
Date: | 1999-12-02 00:56:19 |
Message-ID: | 001b01bf3c60$0b811880$2801007e@cadzone.tpf.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> -----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
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(at)tpf(dot)co(dot)jp
From | Date | Subject | |
---|---|---|---|
Next Message | sk.list | 1999-12-02 08:46:21 | Re: [ADMIN] When postgres will be faster? |
Previous Message | Tom Lane | 1999-12-01 23:26:53 | Re: [HACKERS] NOTICE: AbortTransaction and not in in-progress |