RE: [HACKERS] Re: [GENERAL] drop/rename table and transactions
От | Hiroshi Inoue |
---|---|
Тема | RE: [HACKERS] Re: [GENERAL] drop/rename table and transactions |
Дата | |
Msg-id | NABBINCKAKFCDDKMMJHGMEJFDMAA.Inoue@tpf.co.jp обсуждение исходный текст |
Ответ на | RE: [HACKERS] Re: [GENERAL] drop/rename table and transactions ("Hiroshi Inoue" <Inoue@tpf.co.jp>) |
Ответы |
Re: [HACKERS] Re: [GENERAL] drop/rename table and transactions
(Tom Lane <tgl@sss.pgh.pa.us>)
|
Список | 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 > > 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 commandproperly 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 tillend 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 acquiringAccessExcl- usiveLock. 6) commands/commands.c(ALTER TABLE) ALTER TABLE doesn't release AccessExclusiveLock till end of transaction. I couldn'tfind 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 concreteflaw now. Regards. Hiroshi Inoue Inoue@tpf.co.jp
В списке pgsql-hackers по дате отправления:
Следующее
От: Thomas LockhartДата:
Сообщение: Re: Datetime operators (was: Re: [SQL] Another Date question)