Re: change in LOCK behavior - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: change in LOCK behavior
Date
Msg-id 20121011011118.GF11890@momjian.us
Whole thread Raw
In response to Re: change in LOCK behavior  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: change in LOCK behavior  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Wed, Oct 10, 2012 at 08:43:34PM -0400, Tom Lane wrote:
> > It seems to me that the
> > root of the issue here is that people is not that people expect two
> > snapshots -- indeed, a number of people strongly supported getting rid
> > of that behavior at the time -- but rather that they expect the
> > snapshot to be taken after locks are acquired.
> 
> Sure.  Maybe we can rejigger things in a way that does that, although
> I think the stumbling block is going to be parse-time calls to
> user-defined I/O functions for constants --- which might need a
> snapshot.  It might be possible to redesign things so that all tables
> are locked before we do anything that requires a non-SnapshotNow
> snapshot, and then take a single "planning/execution" snapshot.  But
> that is not this patch, and would be a lot more invasive than this
> patch, and would certainly not be back-patchable to 9.2.
> 
> I think we have to revert and go back to the drawing board on this.

Is reverting going to adversely affect users who are already using the
9.2 behavior?

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + It's impossible for everything to be true. +



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: [PATCH 8/8] Introduce wal decoding via catalog timetravel
Next
From: Bruce Momjian
Date:
Subject: Re: [PATCH 8/8] Introduce wal decoding via catalog timetravel