Re: change in LOCK behavior

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Simon Riggs <simon(at)2ndQuadrant(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Tomas Vondra <tv(at)fuzzy(dot)cz>, Thom Brown <thom(at)linux(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: change in LOCK behavior
Date: 2012-10-11 16:53:40
Message-ID: 19901.1349974420@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

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?

Anyway, I believe that for now we ought to revert and rethink, not look
for band-aid ways of preserving this patch.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2012-10-11 16:56:36 Re: enhanced error fields
Previous Message Andrew Dunstan 2012-10-11 16:42:56 Re: Windows help needed for flex and bison