Re: change in LOCK behavior

On 11 October 2012 17:53, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Simon Riggs <simon(at)2ndQuadrant(dot)com> writes:
>> On 11 October 2012 01:43, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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