From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov> |
Cc: | Noah Misch <noah(at)leadboat(dot)com>, Marti Raudsepp <marti(at)juffo(dot)org>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: RFC: Making TRUNCATE more "MVCC-safe" |
Date: | 2012-02-13 18:07:49 |
Message-ID: | CA+Tgmoa9yoJXr9sFh4cOkGg77GggwBz_LfmizeuP_+mTb3pPjA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Feb 13, 2012 at 10:48 AM, Kevin Grittner
<Kevin(dot)Grittner(at)wicourts(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2012-02-13 18:33:58 | Re: auto_explain produces invalid JSON |
Previous Message | Tom Lane | 2012-02-13 17:48:52 | Re: auto_explain produces invalid JSON |