Hello!
- /* one of SO_TYPE_* may be specified */
+ /*
+ * One of SO_TYPE_* may be specified. When adding a scan type, check
+ * whether it must take predicate locks to be safe under SERIALIZABLE:
see
+ * the flag test in heap_beginscan() and "Heap locking" in
+ * src/backend/storage/lmgr/README-SSI.
+ */
A wider llm-audit based on this claim pointed out that there's one
more preexisting issue: a tid scan that probes a tid holding no tuple
takes no predicate lock of any kind, so a concurrent INSERT that
materialises a tuple at exactly that TID creates no rw-conflict.
I'm not sure what's the proper solution for this, and if it even
should be part of this patch or something separate (as this patch is a
clear improvement even with this leftover issue), but it seems to be
at least worth a mention in a comment/commit message to state the
limitation?
An isolation test reproducing the problem:
setup
{
create table ta (id int);
insert into ta values (1), (2);
create table tb (id int);
insert into tb values (1), (2);
}
teardown { drop table ta; drop table tb; }
session s1
setup { begin isolation level serializable; set enable_seqscan = off; }
step r1 { select count(*) from tb where ctid = '(0,3)'; }
step w1 { insert into ta values (100); }
step c1 { commit; }
session s2
setup { begin isolation level serializable; set enable_seqscan = off; }
step r2 { select count(*) from ta where ctid = '(0,3)'; }
step w2 { insert into tb values (200); }
step c2 { commit; }
permutation r1 r2 w1 w2 c1 c2
