change in LOCK behavior - Mailing list pgsql-hackers

From Tomas Vondra
Subject change in LOCK behavior
Date
Msg-id 5075D8DF.6050500@fuzzy.cz
Whole thread Raw
Responses Re: change in LOCK behavior  ("ktm@rice.edu" <ktm@rice.edu>)
Re: change in LOCK behavior  (Andres Freund <andres@2ndquadrant.com>)
Re: change in LOCK behavior  (Thom Brown <thom@linux.com>)
List pgsql-hackers
Hi,

I've just noticed a change of LOCK command behavior between 9.1 and 9.2,
and I'm not sure whether this is expected or not.

Let's use a very simple table
 CREATE TABLE x (id INT);

Say there are two sessions - A and B, where A performs some operations
on "x" and needs to protect them with an "ACCESS EXCLUSIVE" lock (e.g.
it might be a pg_bulkload that acquires such locks, and we need to do
that explicitly on one or two places).

Session B is attempting to read the data, but is blocked and waits. On
9.1 it sees the commited data (which is what we need) but on 9.2 it sees
only data commited at the time of the lock attemt.

Example:

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).

regards
Tomas




pgsql-hackers by date:

Previous
From: Boszormenyi Zoltan
Date:
Subject: Re: [PATCH] Make pg_basebackup configure and start standby [Review]
Next
From: Daniel Frey
Date:
Subject: Re: Bug / feature request for floating point to string conversion