SELECT FOR UPDATE returns zero rows - postgresql

Question

UPDATE: Problem solved!
That was a bug in PostgreSQL. Tom Lane fixed it in this
commit.
Why SELECT FOR UPDATE returns 0 rows in scenario below? But if I just execute sql query from second transaction it always returns 1 row.
TRANSACTION 1:
BEGIN;
-- This query updates t1c1 to its current value, it doesn't change anything
UPDATE t1 SET t1c3 = 'string_value_1' WHERE t1c1 = 123456789;
-- Query returned successfully: one row affected, 51 msec execution time.
TRANSACTION 2:
WITH
cte1 AS (
SELECT t2c2 FROM t2 WHERE t2c1 = 'string_value_2'
),
cte2 AS (
SELECT * FROM t1
WHERE
t1c1 = 123456789
AND t1c2 = (SELECT t2c2 FROM cte1)
FOR UPDATE
)
SELECT * FROM cte2
-- Waiting
TRANSACTION 1:
COMMIT;
-- Query returned successfully with no result in 41 msec.
TRANSACTION 2:
-- Returned 0 rows
Example:
CREATE TABLE t1 (_pk serial, t1c1 integer, t1c2 integer, t1c3 text);
CREATE TABLE t2 (_pk serial, t2c1 text, t2c2 integer);
insert into t1 (t1c1, t1c2, t1c3) values(123456789, 100, 'string_value_1');
insert into t2 (t2c1, t2c2) values('string_value_2', 100);

Answer 1

Interesting question! With explain verbose analyze, I get the following query plan:
QUERY PLAN
-------------------------------------------------------------------------------------------------------------------
CTE Scan on cte2 (cost=51.13..51.15 rows=1 width=44) (actual time=4544.488..4544.488 rows=0 loops=1)
Output: cte2._pk, cte2.t1c1, cte2.t1c2, cte2.t1c3
CTE cte1
-> Seq Scan on public.t2 (cost=0.00..24.50 rows=6 width=4) (actual time=0.002..0.003 rows=1 loops=1)
Output: t2.t2c2
Filter: (t2.t2c1 = 'string_value_2'::text)
CTE cte2
-> LockRows (cost=0.12..26.63 rows=1 width=50) (actual time=4544.485..4544.485 rows=0 loops=1)
Output: t1._pk, t1.t1c1, t1.t1c2, t1.t1c3, t1.ctid
InitPlan 2 (returns $1)
-> CTE Scan on cte1 (cost=0.00..0.12 rows=6 width=4) (actual time=0.005..0.006 rows=1 loops=1)
Output: cte1.t2c2
-> Seq Scan on public.t1 (cost=0.00..26.50 rows=1 width=50) (actual time=0.018..0.019 rows=1 loops=1)
Output: t1._pk, t1.t1c1, t1.t1c2, t1.t1c3, t1.ctid
Filter: ((t1.t1c1 = 123456789) AND (t1.t1c2 = $1))
Planning time: 0.116 ms
Execution time: 4544.535 ms
(17 rows)
The outer "CTE Scan on cte2" seems to drop the row that was still there during the "LockRows" step. Postgres is known to re-evaluate where clauses after acquiring a lock (see this example with work queues.) Perhaps the query plan contains a where clause on the invisible ctid row identifier, which does change after any UPDATE ?
I've asked this question on the Postgres mailing list to see if other people are able to clarify what's happening here.

Answer 2

I'd say this is a bug in PostgreSQL, and you should report it.

Answer 3

FOR UPDATE has no meaning inside CTE. This should work though:
WITH
cte1 AS (
SELECT t2c2 FROM t2 WHERE t2c1 = "string_value_2"
),
cte2 AS (
SELECT * FROM t1
WHERE
t1c1 = 123456789
AND t1c2 = (SELECT t2c2 FROM cte1)
)
SELECT * FROM cte2 FOR UPDATE