Tomas Vondra <t...@fuzzy.cz> writes: > On 10.10.2012 22:43, Thom Brown wrote: >> On 10 October 2012 21:21, Tomas Vondra <t...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
