On Mon, Feb 13, 2012 at 10:48 AM, Kevin Grittner <kevin.gritt...@wicourts.gov> wrote: > Well, personally I have a hard time calling READ COMMITTED behavior > sensible. Consider this: > > [ gigantic pile of fail ]
Yeah, that's bad all right. I think it's hard to argue that the current behavior is sensible; the trick is to figure out something that's better but doesn't impose too much additional overhead. I wonder if it's possible to use SSI (or some stripped-down mechanism along similar lines) to track these kinds of write conflicts, rather than cluttering the system catalogs with lots more TransactionId fields. Like, when we TRUNCATE a table, we could essentially make a note in memory someplace recording the write conflict. Unfortunately, the full-blown SSI machinery seems too expensive to use for this, especially on all-read workloads where there are no actual conflicts but lots of conflict checks. But that could probably be optimized. The attraction of using something like an in-memory conflict manager is that it would probably be quite general. We could fix problems of this type with no on-disk format changes whenever we discover them (as we will certainly continue to do) just by adding the appropriate flag-a-conflict calls to the right places in the code. -- 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
