Hi,
On 2026-09-21 15:41:54 +0300, Aleksander Alekseev wrote:
> + * For seqscan, sample and TID range scans in a serializable transaction,
> + * acquire a predicate lock on the entire relation. This is required not
> + * only to lock all the matching tuples, but also to conflict with new
> + * insertions into the table. In an indexscan, we take page locks on the
> + * index pages covering the range specified in the scan qual, but in a
> + * heap scan there is nothing more fine-grained to lock. A bitmap scan is
> + * a different story, there we have already scanned the index and locked
> + * the index pages covering the predicate. But in that case we still have
> + * to lock any matching heap tuples. For sample scan we could optimize the
> + * locking to be at least page-level granularity, but we'd need to add
> + * per-tuple locking for that. A TID range scan is like a seqscan in this
> + * respect: it reads heap blocks directly with no index involved, so there
> + * is nothing finer to lock, and heap_insert() only checks for conflicts
> + * against relation-level predicate locks anyway.
> + */
> + if (scan->rs_base.rs_flags & (SO_TYPE_SEQSCAN | SO_TYPE_SAMPLESCAN |
> + SO_TYPE_TIDRANGESCAN))
> {
> /*
> * Ensure a missing snapshot is noticed reliably, even if the
Seems like it'd be good to add a note to the SO_TYPE definitions mentioning
that this needs to be updated for additional scans.
I wish we could easily make the SO_TYPE ones an enum, so we could trigger
compiler warnings here by making it an switch() without a default. But it'd
probably be more annoying to change this than it's worth...
Do we have test coverage for the bitmap scan cases?
Greetings,
Andres Freund
