Re: change in LOCK behavior

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: change in LOCK behavior
Дата
Msg-id 12761.1349910622@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: change in LOCK behavior  (Tomas Vondra <tv@fuzzy.cz>)
Ответы Re: change in LOCK behavior
Список pgsql-hackers
Tomas Vondra <tv@fuzzy.cz> writes:
> On 10.10.2012 22:43, Thom Brown wrote:
>> On 10 October 2012 21:21, Tomas Vondra <tv@fuzzy.cz> wrote:
>>> A: BEGIN;
>>> A: LOCK x IN ACCESS EXCLUSIVE MODE;
>>> A: INSERT INTO x VALUES (100);
>>> B: SELECT * FROM x;
>>> A: COMMIT;
>>> 
>>> Now on 9.1, B receives the value "100" while on 9.2 it gets no rows.
>>> 
>>> Is this expected? I suspect the snapshot is read at different time or
>>> something, but I've checked release notes but I haven't seen anything
>>> relevant.
>>> 
>>> Without getting the commited version of data, the locking is somehow
>>> pointless for us (unless using a different lock, not the table itself).

>> I suspect it's this commit: d573e239f03506920938bf0be56c868d9c3416da
>> http://archives.postgresql.org/pgsql-committers/2011-12/msg00167.php

> Maybe, the description suggests it might be related. I'm still not sure
> whether this is a bug or expected behavior, although the commit clearly
> states that the change shouldn't be user-visible.

Yeah, I think that last is the key point: this patch was sold on the
grounds that it wouldn't cause any interesting user-visible behavioral
change, but your example blows that claim into tiny little pieces.

I'm inclined to think we need to revert this.  The performance gain is
not worth the prospect of breaking a lot of applications that used to
work reliably.  Robert?
        regards, tom lane



В списке pgsql-hackers по дате отправления:

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