On Sat, Jul 09, 2005 at 11:48:35AM -0400, Tom Lane wrote:
> Stephen Frost <sfrost@snowman.net> writes:
> > * Mike Mascari (mascarm@mascari.com) wrote:
> >> And when the transaction that issued the TRUNCATE aborts after step 3,
> >> but newer transactions commit?
>
> > The newer transactions would have to check for that situation.
>
> How would they do that? They might be long gone by the time the
> truncating transaction rolls back.
>
> It might be possible to do something that preserves full MVCC-ness for
> concurrent readers, but I don't believe there is any choice but to lock
> out concurrent writers until the truncate commits. If you try to allow
> that, there's no way to keep straight whose change goes into which file.
What about if inserts go into both files until the truncate commits?
Updates are a bit trickier; AFAICS they would have to block until the
truncate commits because they would have different effects depending on
if the commit happenend or not. But I don't see this as an issue.
Likewise, inserts that would violate a unique constraint would have to
wait until the truncate committed, but inserts that are unique could
commit.
Of course something else to consider is that just being able to support
concurrent reads against truncate would be a step forward, even if
writes were still blocked. That alone means this is probably
worth-while, although it might require a slightly different syntax since
it would behave differently than the existing truncate does.
--
Jim C. Nasby, Database Consultant decibel@decibel.org
Give your computer some brain candy! www.distributed.net Team #1828
Windows: "Where do you want to go today?"
Linux: "Where do you want to go tomorrow?"
FreeBSD: "Are you guys coming, or what?"