From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Florian G(dot) Pflug" <fgp(at)phlo(dot)org> |
Cc: | Postgresql-General <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Is the "ACCESS EXCLUSIVE" lock for TRUNCATE really necessary? |
Date: | 2006-03-07 03:33:54 |
Message-ID: | 12719.1141702434@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
"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.
There's been some discussion of using MVCC semantics on catalog
accesses, but we are very far from being ready to do that; the
implications will reach into every part of the backend. To give just
one example of why this isn't necessarily a hot idea, suppose that
transaction A adds a constraint to a table T and commits, and then
transaction B (which started before A and hasn't previously touched T)
comes along and inserts a tuple into T that violates the constraint.
If B uses an old snapshot for looking up T's catalog info then it will
not see the constraint that it must satisfy. Locking does not help
since A released its locks on T before B would have tried to take any
lock.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Fuhr | 2006-03-07 04:45:03 | Re: Data corruption zero a file - help!! |
Previous Message | Tom Lane | 2006-03-07 03:04:26 | Re: ERROR: xlog flush request not satisfied |