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

On Fri, Dec 07, 2012 at 06:51:18PM -0500, Stephen Frost wrote:
> * Jeff Davis (pgsql(at)j-davis(dot)com) wrote:
> > Most of your concerns seem to be related to freezing, and I'm mostly
> > interested in HEAP_XMIN_COMMITTED optimizations. So I think we're
> > talking past each other.
>
> My concern is about this patch/capability as a whole. I agree that the
> hint bit setting may be fine by itself, I'm not terribly concerned with
> that. Now, if you (and others) aren't concerned about the overall
> behavior that is being introduced here, that's fine, but it was my
> understanding from previous discussions that making tuples visible to
> all transactions, even those started before the committing transaction
> which are set more strictly than 'read-committed', wasn't 'ok'.
>
> Now, what I've honestly been hoping for on this thread was for someone
> to speak up and point out why I'm wrong about this concern and explain
> how this patch addresses that issue. If that's been done, I've missed
> it..

I favor[1] unconditionally letting older snapshots see the new rows after the
CREATE+COPY transaction commits. To recap, making affected scans see an empty
table is as wrong as making them see those rows. Robert also listed[2] that
as a credible option, and I don't recall anyone opining against it in previous
discussions. I did perceive an undercurrent preference, all other things
being equal, for an optimization free from semantic side-effects. I shared
that preference, but investigations showed that we must compromise something.

Though I like the idea of making new relations appear nonexistent to older
snapshots, let's keep that as an independent patch. Otherwise, the chance of
having none of the above in PostgreSQL 9.3 escalates significantly.

Thanks,
nm

[1] http://archives.postgresql.org/message-id/20120302205834.GC29160@tornado.leadboat.com
[2] http://archives.postgresql.org/message-id/CA+TgmoYh_KXErp9eOejMV6EJJaczeZZcSj3kRtq=yg1SjiMidg@mail.gmail.com