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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
