Re: Commits 8de72b and 5457a1 (COPY FREEZE) - Mailing list pgsql-hackers

From Jeff Davis
Subject Re: Commits 8de72b and 5457a1 (COPY FREEZE)
Date
Msg-id 1355204027.21959.1.camel@jdavis
Whole thread Raw
In response to Re: Commits 8de72b and 5457a1 (COPY FREEZE)  (Stephen Frost <sfrost@snowman.net>)
List pgsql-hackers
On Mon, 2012-12-10 at 08:16 -0500, Stephen Frost wrote: 
> I'm trying to figure out why there are all the constraints around this
> command to begin with.  If we're going to support this, why do we
> require the user to create or truncate the table in the same
> transaction?  Clearly that's going to reduce the usefulness of this
> feature and it's not clear to me why that constraint is needed,
> code-wise.

There is a very specific reason:

If you insert frozen tuples into a table that already has tuples in it,
then you no longer have just an isolation issue, you have an *atomicity*
issue (and probably a number of other serious issues) because you can't
roll back. Doing it in the same transaction as the table was created
leaves you with a way to roll back: just delete the table (which will
happen implicitly because the creation is part of the same transaction
anyway).

Perhaps we can take some partial steps toward MVCC-safe access? For
instance, how about trying to recheck the xmin of a pg_class tuple when
starting a scan?

Regards,Jeff Davis




pgsql-hackers by date:

Previous
From: Josh Kupershmidt
Date:
Subject: allowing multiple PQclear() calls
Next
From: Jeff Davis
Date:
Subject: Re: MySQL search query is not executing in Postgres DB