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
