On Thu, 2012-12-06 at 22:34 -0500, Stephen Frost wrote: > * Jeff Davis (pg...@j-davis.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers