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

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

In response to

Responses

Browse pgsql-hackers by date

  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