On Thu, 2012-12-06 at 14:18 -0500, Stephen Frost wrote: > begin; > You need to do a SELECT here to actually get a snapshot.
> session b > --------- > begin; > create table q (a > integer); > insert into q values > (1); > commit; > > select * from q; > > > You'll get an empty table. That's not great, but it's life- once > something is in pg_class, all sessions can see it because the table > lookups are done using SnapshotNow and aren't truely transactional, but > at least you can't see any rows in the table because the individual rows > are marked with the transaction ID which created them and we can't see > them in our transaction that started before the table was created. > > It sounds like, with this patch/change, this behavior would change. No, it would not change. Session A would see that the table exists and see that the rows' inserting transaction (in Session B) committed. That is correct because the inserting transaction *did* commit, and it's the same as we have now. However, the rows will *not* be visible, because the serializable snapshot doesn't contain the inserting transaction. Think about the current behavior: right after the commit, another select could come along and set all those hint bits anyway. Even if the hint bits aren't set, it will do a CLOG lookup and find that the transaction committed. The change being proposed is just to set those hint bits preemptively, because the fate of the INSERT is identical to the fate of the CREATE (they are in the same transaction). There will be no observable problem outside of that CREATE+INSERT transaction. The only catch is what to do about visibility of the tuples when still inside the transaction (which is not a problem for transactions doing a simple load). The interesting thing about HEAP_XMIN_COMMITTED is that it can be set preemptively if we know that the transaction will actually commit (aside from the visibility issues within the transaction). Even if the transaction doesn't commit, it would still be possible to clean out the dead tuples with a VACUUM, because no information has really been lost in the process. So there may yet be some kind of safe protocol to set these even during a load into an existing table... Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers