Re: change in LOCK behavior

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

Of course not. This performance improvement is simply lost for 9.2.
We can try to do better in future releases, but it's a failed experiment
for now. Life is hard :-(

> I suggested a way to automatically trigger a second snapshot. I think
> that would be acceptable to backpatch.

If it worked, I might be amenable to that, but it doesn't. You can't
trigger taking a new snapshot off whether we waited for a lock; that
still has race conditions, just ones that are not so trivial to
demonstrate manually. (The other transaction might have committed
microseconds before you reach the point of waiting for the lock.)
It would have to be a rule like "take a new snapshot if we acquired
any new lock since the previous snapshot". While that would work,
we'd end up with no performance gain worth mentioning, since there
would almost always be some lock acquisitions during parsing.

regards, tom lane