On Mon, Feb 13, 2012 at 10:48 AM, Kevin Grittner
<Kevin.Grittner@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
