Simon Riggs wrote:
> On Fri, 2010-01-29 at 15:01 +0000, Simon Riggs wrote:
>
>> Putting it back takes time and
>> given enough of that rare cloth, it will eventually be put back.
>
> Looks like I'll have time to add the starts-at-shutdown-checkpoint item
> back in after all.
Great! Thank you, much appreciated.
> 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.
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com