On Tue, 2010-02-02 at 20:27 +0200, Heikki Linnakangas wrote:
> > I'd appreciate it if you could review the relation-specific conflict
> > patch, 'cos it's still important.
>
> One fundamental gripe I have about that approach is that it's hard to
> predict when you will be saved by the cache and when your query will be
> canceled. For example, the patch stores only one "latestRemovedXid"
> value per lock partition. So if you have two tables that hash to
> different lock partitions, and are never both accessed in a single
> transaction, the cache will save your query every time. So far so good,
> but then you do a dump/restore, and the tables happen to be assigned to
> the same lock partition. Oops, a system that used to work fine starts to
> get "snapshot too old" errors.
>
> It's often better to be consistent and predictable, even if it means
> cancelling more queries. I think wë́'d need to have a much more
> fine-grained system before it's worthwhile to do deferred resolution.
> There's just too much "false sharing" otherwise.
ISTM that this is exactly backwards. There is already way too many false
positives and this patch would reduce them very significantly. Plus the
cancelation is hardly predictable since it relies on whether or not a
btree delete takes place during execution and the arrival time and rate
of those is sporadic. There is no safe, predicatable behaviour in the
current code.
The gripe about the cache cannot be a fundamental one, since we can
easily change the size and mechanism by which the cache operates without
changing the patch very much at all.
I am being told this area is a must-fix issue for this release. Tom's
reaction to this issue (on other thread) illustrates that beautifully:
On Sun, 2010-01-31 at 15:41 -0500, Tom Lane wrote:
> Simon Riggs <simon@2ndQuadrant.com> writes:
(snip)
> > 2. no matter if they haven't accessed the index being cleaned (they
> > might later, is the thinking...)
>
> That seems seriously horrid. What is the rationale for #2 in
> particular? I would hope that at worst this would affect sessions
> that are actively competing for the index being cleaned.
-- Simon Riggs www.2ndQuadrant.com