Re: relation ### modified while in use
От
Alex Pilosov
Тема
Re: relation ### modified while in use
Дата
Msg-id
Pine.BSO.4.10.10010230115280.22422-100000@spider.pilosoft.com
Ответ на
Re: relation ### modified while in use (Tom Lane)
Список
Дерево обсуждения
relation ### modified while in use Alex Pilosov <alex@pilosoft.com>
Re: relation ### modified while in use Tom Lane <tgl@sss.pgh.pa.us>
Re: relation ### modified while in use Alex Pilosov <alex@pilosoft.com>
Re: relation ### modified while in use Tom Lane <tgl@sss.pgh.pa.us>
Re: relation ### modified while in use Philip Warner <pjw@rhyme.com.au>
Re: relation ### modified while in use Tom Lane <tgl@sss.pgh.pa.us>
Re: relation ### modified while in use Philip Warner <pjw@rhyme.com.au>
Re: relation ### modified while in use Alex Pilosov <alex@pilosoft.com>
Re: relation ### modified while in use Tom Lane <tgl@sss.pgh.pa.us>
Re: relation ### modified while in use Alex Pilosov <alex@pilosoft.com>
Re: relation ### modified while in use Alex Pilosov <alex@pilosoft.com>
Re: relation ### modified while in use Tom Lane <tgl@sss.pgh.pa.us>
On Mon, 23 Oct 2000, Tom Lane wrote: > begin; > select * from foo; -- gets AccessShareLock > LOCK TABLE foo; -- gets AccessExclusiveLock > ... > end; > > this will work currently because the SELECT releases AccessShareLock > when done, but it will deadlock if SELECT does not release that lock. Probably a silly question, but since this is the same transaction, couldn't the lock be 'upgraded' without a problem? Or postgres doesn't currently have idea of lock upgrades...? -alex
В списке pgsql-hackers по дате отправления