On Mon, May 20, 2019 at 10:23 AM Andres Freund <andres@anarazel.de> wrote:
> On 2019-05-19 13:57:42 +1200, Thomas Munro wrote:
> > Yeah, we could probably predicate-lock pages in
> > heapam_scan_sample_next_block() and tuples in
> > heapam_scan_sample_next_tuple(), instead of doing this. Seems like a
> > reasonable improvement for 13. But... hmm.... There *might* be a
> > theoretical argument about TABLESAMPLE(100) behaving differently if
> > done per page rather than if done at relation level, wrt new pages
> > added to the end later and therefore missed. And then by logical
> > extension, TABLESAMPLE of any percentage. I'm not sure.
>
> I don't think that's actually a problem, tablesample doesn't return
> invisible rows. And the equivalent issue is true just as well for index
> and bitmap heap scans?
It affects whether this transaction could be considered to have run
after the other transaction though. The equivalent issue is handled
for index scans, because we arrange to predicate lock pages that
anyone else will have to touch if they insert index tuples that would
match your WHERE clause (ie your predicate), as the comment says. (I
wondered if there'd be a finer grained way to do it by
predicate-locking the page-after-last to detect extension, but I
suspect you might really need to lock all-the-pages-after-last... I
don't know.)
--
Thomas Munro
https://enterprisedb.com
