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

From: "Florian G(dot) Pflug" <fgp(at)phlo(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Postgresql-General <pgsql-general(at)postgresql(dot)org>
Subject: Re: Is the "ACCESS EXCLUSIVE" lock for TRUNCATE really
Date: 2006-03-07 13:14:55
Message-ID: 440D874F.1010104@phlo.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Tom Lane wrote:
> "Florian G. Pflug" <fgp(at)phlo(dot)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

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Andrei 2006-03-07 13:58:32 real - integer type cast in prepared statements
Previous Message Peter Eisentraut 2006-03-07 12:15:13 Re: pg_dump error - filesystem full