Re: Commits 8de72b and 5457a1 (COPY FREEZE)

From: Jeff Davis <pgsql(at)j-davis(dot)com>
To: Stephen Frost <sfrost(at)snowman(dot)net>
Cc: Simon Riggs <simon(at)2ndQuadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Commits 8de72b and 5457a1 (COPY FREEZE)
Date: 2012-12-11 05:33:47
Message-ID: 1355204027.21959.1.camel@jdavis
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jeff Davis 2012-12-11 05:59:44 Re: MySQL search query is not executing in Postgres DB
Previous Message Josh Kupershmidt 2012-12-11 04:59:45 allowing multiple PQclear() calls