Re: change in LOCK behavior

Поиск
Список
Период
Сортировка
От Bruce Momjian
Тема Re: change in LOCK behavior
Дата
Msg-id 20121011011118.GF11890@momjian.us
обсуждение исходный текст
Ответ на Re: change in LOCK behavior  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: change in LOCK behavior  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: [PATCH 8/8] Introduce wal decoding via catalog timetravel
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: [PATCH 8/8] Introduce wal decoding via catalog timetravel