On 3 January 2012 18:42, Tom Lane <t...@sss.pgh.pa.us> wrote: > I wrote: >>> Another point that requires some thought is that switching SnapshotNow >>> to be MVCC-based will presumably result in a noticeable increase in each >>> backend's rate of wanting to acquire snapshots. > > BTW, I wonder if this couldn't be ameliorated by establishing some > ground rules about how up-to-date a snapshot really needs to be. > Arguably, it should be okay for successive SnapshotNow scans to use the > same snapshot as long as we have not acquired a new lock in between. > If not, reusing an old snap doesn't introduce any race condition that > wasn't there already.
Now that has been implemented using the above design, we can resubmit the lock level reduction patch, with thanks to Robert. Submitted patch passes original complaint/benchmark. Changes * various forms of ALTER TABLE, notably ADD constraint and VALIDATE * CREATE TRIGGER One minor coirrections to earlier thinking with respect to toast tables. That might be later relaxed. Full tests including proof of lock level reductions, plus docs. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
reduce_lock_levels.v13.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
