sample scans and predicate locking

From: Andres Freund <andres(at)anarazel(dot)de>
To: pgsql-hackers(at)postgresql(dot)org, Petr Jelinek <petr(at)2ndquadrant(dot)com>
Cc: Kevin Grittner <kgrittn(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
Subject: sample scans and predicate locking
Date: 2019-05-18 20:31:02
Message-ID: 20190518203102.g7peu2fianukjuxm@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

While looking at fixing [1] on master, I noticed the following
codeblock:

static HeapScanDesc
heap_beginscan_internal(Relation relation, Snapshot snapshot,
int nkeys, ScanKey key,
ParallelHeapScanDesc parallel_scan,
bool allow_strat,
bool allow_sync,
bool allow_pagemode,
bool is_bitmapscan,
bool is_samplescan,
bool temp_snap)
...
/*
* For a seqscan 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.
*/
if (!is_bitmapscan)
PredicateLockRelation(relation, snapshot);

As you can see this only tests for is_bitmapscan, *not* for
is_samplescan. Which means we afaict currently every sample scan
predicate locks the entire relation.

I think there's two possibilities here:

1) It's just the comment that's inaccurate, and it should really talk
about both seqscans and sample scans. It should not be necessary to
lock the whole relation, but I'm not sure the code otherwise takes
enough care.

2) We should really not predicate lock the entire relation. In which
case I think there might be missing PredicateLockTuple/Page calls.

Greetings,

Andres Freund

[1] https://postgr.es/m/4EA80A20-E9BF-49F1-9F01-5B66CAB21453%40elusive.cx

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tomas Vondra 2019-05-18 23:28:12 Re: Multivariate MCV stats can leak data to unprivileged users
Previous Message Peter Geoghegan 2019-05-18 20:21:38 Re: itemptr_encode/itemptr_decode