Re: [HACKERS] It sorta works, but I'm confused about locking
От | Bruce Momjian |
---|---|
Тема | Re: [HACKERS] It sorta works, but I'm confused about locking |
Дата | |
Msg-id | 199810020224.WAA23350@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] It sorta works, but I'm confused about locking (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
> Bruce Momjian <maillist@candle.pha.pa.us> writes: > > I recommend you check out what is currently done properly, and fix the > > ones that are incorrect. > > Well, yes. The question was how to tell which is which :-) I didn't say it was easy. :-) > > > I can imagine some cases where you would want to get a lock and keep it > > until the end of the transaction, and other times when you would want to > > release it before transaction end. > > I guess I'm not understanding something. How can it ever be correct > practice to release a lock before transaction end? For example, if I > write some changes in a table, and then release the lock, wouldn't that > allow other backends to see the not-yet-committed changes? What if I > then abort my transaction? Now the other backends have acted on > information they should never have seen at all. > > Releasing a read lock strikes me as just as dangerous but for more > subtle reasons --- once you have read a table, what you have read > ought to look the same until the end of your transaction. > > Since there is an unset-write-lock function, I assume it must have > valid uses, but I don't see what they are. Suppose you want to update a table as part of internal query processing. You lock it, update it, and unlock it. You just need the lock while you are updating it. > > >> Is there a bug here, or is there some special definition of user access > >> to a system table that means the select isn't acquiring a read lock? > >> Selects and updates on ordinary user tables seem to interlock fine... > > > Select certainly should be locking. Something is wrong, but I am not > > sure what. If you want me to check into it, let me know. > > Please. (Note that I saw this with my revised version of async.c; > I believe you will see the same behavior with the currently-checked-in > code, but do not have the time to rebuild that version to make sure.) -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
В списке pgsql-hackers по дате отправления: