> -----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.
>
> Now that read and write locks don't interfere with each other, this may
> not be as big a performance loss as it sounds.
>
> But, do you intend to apply this principle to system tables as well as
> user tables?
Yes I said about only system tables.
Isn't an early release of lock for user tables is already a bug ?(except
AccessShareLock).
> I am concerned that we will have deadlock problems if we
> try to do it for system tables, because practically all transactions
> will start out with system-table accesses, which implies grabbing a read
> lock on those system tables if you want to take a hard line about it.
> If you later need to upgrade to a higher-grade lock on any of those
> system tables, you've got trouble.
>
Sorry,my target is only executor stage this time and AccessShareLock
is an exception.
As for parser/planner stage,it needs further consideration and I don't
have any solution yet. SPI already has an ability to prepare plans and
executor could use them in other transactions. We have to draw a
clear line between executor and parse/planner. Probably plan invalidation
mecahnism will be needed and we may have to put plans on shared
memory to realize it.
>
> > If we don't allow DDL command inside transaction block,we won't need
> > the release before end of transaction.
> > If we allow DDL command inside transaction block,it may be a problem.
> > But are there any other principles which could guarantee consistency ?
>
> I certainly do not wish to give up the goal of supporting DDL statements
> inside transactions. What problems do you foresee?
>
I may be the first man that threw a question about DDL commands inside
transactions. I'm stiil suspicious about the possibility.
I have thought about the following. I think they should be considered
even in case of DDL commands *outside* transactions.
1) The biggest obstacle for me is this early release of lock(including parser/planner handling). Without a solution
forthis I couldn't see any consistency for system tuples.
2) The implementation of row level share locking.
3) The naming of relation files which has been discussed in this thread.
4) The lack of read consistency in DDL statement though I couldn't tell concretely what's wrong with it.
Regards.
Hiroshi Inoue
Inoue@tpf.co.jp
