From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
---|---|
To: | Stephen Frost <sfrost(at)snowman(dot)net> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Commits 8de72b and 5457a1 (COPY FREEZE) |
Date: | 2012-12-07 23:09:36 |
Message-ID: | 1354921776.4530.255.camel@sussancws0025 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, 2012-12-06 at 22:34 -0500, Stephen Frost wrote:
> * Jeff Davis (pgsql(at)j-davis(dot)com) wrote:
> > 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.
>
> Strictly speaking, it could actually be two different uesrs..
That's a good point. Somewhat like SERIALIZABLE, unless everyone is on
board, it doesn't really work.
> > 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.
>
> Actually, no, I'm not convinced of that. If a seperate transaction
> starts before the create/insert, and is still open when the create/insert
> transaction commits, wouldn't that seperate transaction see rows in the
> newly created table?
Not if all you do is set HEAP_XMIN_COMMITTED. Committed <> visible.
> That's more-or-less the specific issue I'm bringing up as a potential
> concern. If it's just a FrozenXID stored in the heap and there isn't
> anything telling the 2nd transaction to not consider this table that
> exists through SnapshotNow, how are we going to know to not look at the
> tuples? Or do we accept that it's "ok" for those to be visible?
I am talking about HEAP_XMIN_COMMITTED. I think it's understood that
freezing has much stricter requirements for safety in various situations
because it loses information.
> How I wish we could fix the table visibility and not have to worry about
> this issue at all, which would also remove the need for some special
> keyword to be used to tell us it's 'ok' to use this optimization...
I think we need to be clear about which one we're discussing:
HEAP_XMIN_COMMITTED or FrozenXID. I believe discussing them together has
caused a significant amount of confusion in this thread.
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.
Regards,
Jeff Davis
From | Date | Subject | |
---|---|---|---|
Next Message | Stephen Frost | 2012-12-07 23:51:18 | Re: Commits 8de72b and 5457a1 (COPY FREEZE) |
Previous Message | Dimitri Fontaine | 2012-12-07 22:01:57 | Re: ALTER TABLE ... NOREWRITE option |