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 1354849654.4530.193.camel@sussancws0025
Whole thread Raw
In response to Re: Commits 8de72b and 5457a1 (COPY FREEZE)  (Stephen Frost <sfrost@snowman.net>)
Responses Re: Commits 8de72b and 5457a1 (COPY FREEZE)  (Stephen Frost <sfrost@snowman.net>)
List pgsql-hackers
On Thu, 2012-12-06 at 20:49 -0500, Stephen Frost wrote:
> I'm less concerned about the hint bits and more concerned about the
> implications of the FrozenXID being used, which would make the rows
> visible to other transactions even if they began before the rows were
> loaded.

That is documented in the committed patch -- it's a trade, basically
saying that you lose isolation but avoid extra writes. It seems
reasonable that the user gets this behavior if specifically requested.

> My concern is more about what happens to transactions which are opened
> before this transaction commits and that they might be able to see data
> in the table.

In the simple approach that only affects loads in the same transaction
as the create, this is not an issue. The only issue there is for other
reads in the same transaction. I think you already know that, but I am
repeating for clarity.

> As I mentioned before, I'm not *convinced* that this is really a big
> deal, or even a problem for this patch, but it's something to *consider*
> and think about because, as much as we like to say that DDL is
> transaction-safe, it's *not* completely MVCC and things like creating
> tables and committing them will show up as visible even in transactions
> that shouldn't be able to see them.  Due to that, we need to think about
> what happens with data in those tables, etc.

Agreed. I don't think anyone is suggesting that we change the semantics
of existing commands, unless it's to improve the serializability of DDL.

Regards,Jeff Davis




pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: pg_upgrade problem with invalid indexes
Next
From: Bruce Momjian
Date:
Subject: Re: pg_upgrade problem with invalid indexes