On Fri, Feb 10, 2012 at 6:42 AM, Noah Misch <n...@leadboat.com> wrote: > I like the design you have chosen. It would find applications beyond > TRUNCATE, so your use of non-specific naming is sound. For example, older > snapshots will see an empty table "t" after "CREATE TABLE t AS SELECT 1" > commits; that's a comparable MVCC anomaly. Some of our non-MVCC-safe commands > should perhaps just become MVCC-safe, but there will always be use cases for > operations that shortcut MVCC. When one truly does want that, your proposal > for keeping behavior consistent makes plenty of sense.
I guess I'm not particularly excited by the idea of trying to make TRUNCATE MVCC-safe. I notice that the example involves the REPEATABLE READ isolation level, which is already known to be busted in a variety of ways; that's why we now have SERIALIZABLE, and why most people use READ COMMITTED. Are there examples of this behavior at other isolation levels? But I have to admit I'm intrigued by the idea of extending this to other cases, if there's a reasonable way to do that. For example, if we could fix things up so that we don't see a table at all if it was created after we took our snapshot, that would remove one of the obstacles to marking pages bulk-loaded into that table with FrozenXID and PD_ALL_VISIBLE from the get-go. I think a lot of people would be mighty happy about that. But the necessary semantics seem somewhat different. For TRUNCATE, you want to throw a serialization error; but is that also what you want for CREATE TABLE? Or do you just want it to appear empty? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
