Re: Is the "ACCESS EXCLUSIVE" lock for TRUNCATE really

Поиск
Список
Период
Сортировка
От Florian G. Pflug
Тема Re: Is the "ACCESS EXCLUSIVE" lock for TRUNCATE really
Дата
Msg-id 440D874F.1010104@phlo.org
обсуждение исходный текст
Ответ на Re: Is the "ACCESS EXCLUSIVE" lock for TRUNCATE really necessary?  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-general
Tom Lane wrote:
> "Florian G. Pflug" <fgp@phlo.org> writes:
>>Tom Lane wrote:
>>
>>>Until when?  How would you synchronize the switchover?
>
>>Every snapshot would either contain the old, or the new version of
>>the corresponding pg_class tuple. The ones using the old version
>>couldn't possible be writer, only reader (TRUNCATE would still need
>>to acquire a lock that ensures that). New transactions started after
>>the commit of the truncate would see the new version, and use
>>the new datafile.
>
> Wrong.  *All* transactions read the system catalogs with SnapshotNow.
Ah, well that clearly kills my idea... Too bad...

I was fooled by the fact that most ddl-statements can be rolled back,
and assumed that this follows from using "normal" mvcc semantics when
reading the catalog tables.

Thanks for your explanations!

greetings, Florian Pflug

В списке pgsql-general по дате отправления:

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Re: pg_dump error - filesystem full
Следующее
От: Andrei
Дата:
Сообщение: real - integer type cast in prepared statements