On 3 January 2012 18:42, Tom Lane wrote:
I wrote:
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.
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.
to be MVCC-based will presumably result in a noticeable increase in each
backend's rate of wanting to acquire snapshots.
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.
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
