On 11 October 2012 17:53, Tom Lane <t...@sss.pgh.pa.us> wrote: > Simon Riggs <si...@2ndquadrant.com> writes: >> On 11 October 2012 01:43, Tom Lane <t...@sss.pgh.pa.us> wrote: >>> I think we have to revert and go back to the drawing board on this. > >> Given that change was also sold on the basis of higher performance, I >> suggest we retest performance to check there is a gain. If there is >> still a gain, I suggest we add this as a SIGHUP option, default to >> off, rather than completely remove it. > > I'm not in favor of adding a GUC for this. The right fix is to redesign > the locking/snapshotting process, not expose its warts in bizarre little > knobs that make users deal with the tradeoffs.
While I agree with that thought, I'd like to try a little harder than simply revert. > Maybe what we really need is to find a way to make taking a snapshot a > lot cheaper, such that the whole need for this patch goes away. We're > not going to get far with the idea of making SnapshotNow MVCC-safe > unless it becomes a lot cheaper to get an MVCC snapshot. I recall some > discussion of trying to reduce a snapshot to a WAL offset --- did that > idea crash and burn, or is it still viable? I think that is still at the "fond wish" stage and definitely not backpatchable in this universe. > Anyway, I believe that for now we ought to revert and rethink, not look > for band-aid ways of preserving this patch. I suggested a way to automatically trigger a second snapshot. I think that would be acceptable to backpatch. But since I'm leaving this to you, I'll leave that decision to you as well. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
