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

From Stephen Frost
Subject Re: Commits 8de72b and 5457a1 (COPY FREEZE)
Date
Msg-id 20121207014922.GD12354@tamriel.snowman.net
Whole thread Raw
In response to Re: Commits 8de72b and 5457a1 (COPY FREEZE)  (Jeff Davis <pgsql@j-davis.com>)
Responses Re: Commits 8de72b and 5457a1 (COPY FREEZE)
List pgsql-hackers
Jeff,

* Jeff Davis (pgsql@j-davis.com) wrote:
> On Thu, 2012-12-06 at 20:12 -0500, Stephen Frost wrote:
> > The command is 'FREEZE', which sounded to me like the transaction ID
> > would be set to FrozenXID, meaning that we wouldn't be able to tell if
> > the inserting transaction was before or after ours...
>
> Freezing does lose information, but I thought that this sub-thread was
> about the HEAP_XMIN_COMMITTED optimization that was in the first version
> of the commit but removed in a later commit. Setting HEAP_XMIN_COMMITTED
> does not lose information.

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 should really be: "aside from the visibility issues before it does
> commit".

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.

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.

> Anyway, the HEAP_XMIN_COMMITTED loading optimizations require more
> discussion, but I think they are worth pursuing. The simpler form is
> when the table is created and loaded in the same transaction, but there
> may be some more sophisticated approaches, as well.

Sure.
Thanks,
    Stephen

pgsql-hackers by date:

Previous
From: Jeff Davis
Date:
Subject: Re: pg_upgrade problem with invalid indexes
Next
From: Michael Paquier
Date:
Subject: Re: [WIP] pg_ping utility