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
Ответ на
Список
Дерево обсуждения
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 по дате отправления
От: Alex Pilosov
Дата:
От: Tom Lane
Дата:
FAQ