PostgreSQL FOR UPDATE with ORDER BY and LIMIT interation - sql

Question

According to https://www.postgresql.org/docs/9.5/static/sql-select.html
It is possible for a SELECT command running at the READ COMMITTED
transaction isolation level and using ORDER BY and a locking clause to
return rows out of order. This is because ORDER BY is applied first.
The command sorts the result, but might then block trying to obtain a
lock on one or more of the rows. Once the SELECT unblocks, some of the
ordering column values might have been modified, leading to those rows
appearing to be out of order (though they are in order in terms of the
original column values). This can be worked around at need by placing
the FOR UPDATE/SHARE clause in a sub-query, for example
SELECT * FROM (SELECT * FROM mytable FOR UPDATE) ss ORDER BY column1;
Note that this will result in locking all rows of mytable, whereas FOR
UPDATE at the top level would lock only the actually returned rows.
This can make for a significant performance difference, particularly
if the ORDER BY is combined with LIMIT or other restrictions. So this
technique is recommended only if concurrent updates of the ordering
columns are expected and a strictly sorted result is required.
At the REPEATABLE READ or SERIALIZABLE transaction isolation level
this would cause a serialization failure (with a SQLSTATE of '40001'),
so there is no possibility of receiving rows out of order under these
isolation levels.
Let's say I run this query,
SELECT * FROM banks as x WHERE x.date < {inputDate} ORDER BY x.date DESC LIMIT 1 FOR UPDATE;
Assume row date can not be modified
Possible to INSERT / DELETE row for banks
Will I be safe to get the correct result every time regardless of race condition?
Will the single row that I retrieved be LOCK FOR UPDATE? (I read many sources regarding interaction of LIMIT and FOR UPDATE, and still is quite confused, can someone confirm what is really going to happen for this case?)
The article mentioned incorrect order, but I can really apply to my use case whether I will get the correct result when add / delete is going on.

Answer 1

Yes, your query can return a wrong result.
See this example:
CREATE TABLE banks (
id integer PRIMARY KEY,
date timestamp with time zone NOT NULL
);
INSERT INTO banks VALUES (1, '2017-09-01 00:00:00');
INSERT INTO banks VALUES (2, '2017-09-01 01:00:00');
Now, in one session we start a transaction that updates a row:
BEGIN;
UPDATE banks
SET date = '2017-08-01 00:00:00'
WHERE id = 2;
Then, in another session, we run your statement:
SELECT *
FROM banks AS x
WHERE x.date < current_timestamp
ORDER BY x.date DESC
LIMIT 1
FOR UPDATE;
This session will hang as it tries to lock the row with id = 2.
Now in the first session, close the transaction:
COMMIT;
Then the second session will unblock and return a wrong result:
┌────┬────────────────────────┐
│ id │ date │
├────┼────────────────────────┤
│ 2 │ 2017-08-01 00:00:00+02 │
└────┴────────────────────────┘
(1 row)
This is because the query returns the row identified before locking it, but the values displayed are the current ones from after the lock has succeeded.