Re: Synchronized scans - Mailing list pgsql-patches

From Tom Lane
Subject Re: Synchronized scans
Date
Msg-id 25556.1181314834@sss.pgh.pa.us
Whole thread Raw
In response to Re: Synchronized scans  (Heikki Linnakangas <heikki@enterprisedb.com>)
Responses Re: Synchronized scans  (Heikki Linnakangas <heikki@enterprisedb.com>)
List pgsql-patches
Heikki Linnakangas <heikki@enterprisedb.com> writes:
> BTW: Should we do the synchronization in the non-page-at-a-time mode?
> It's not many lines of code to do so, but IIRC that codepath is only
> used for catalog access. System tables really shouldn't grow that big,
> and if they do we shouldn't be doing seq scans for them anyway.

It occurs to me that there's an actual bug here for catalog access.
The code assumes that it can measure rs_nblocks only once and not worry
about tuples added beyond that endpoint.  But this is only true when
using an MVCC-safe snapshot.  In SnapshotNow mode, in particular, this
could easily lead to missing a valid tuple.  I'm not sure such a bug
has ever been seen in the wild, because we don't do that many heapscans
on system catalogs (and most of the ones we do do have some amount of
higher-level locking preventing a concurrent update).  But we ought to
fix it while we're touching the code now.  That will take re-measuring
rs_nblocks each time we consider stopping, and I think we definitely
will NOT want the syncscan code getting involved.

I'll take care of incorporating this point into your mod-4 patch.

            regards, tom lane

pgsql-patches by date:

Previous
From: Tom Lane
Date:
Subject: Re: [HACKERS] [BUGS] BUG #3326: Invalid lower bound of autovacuum_cost_limit
Next
From: Heikki Linnakangas
Date:
Subject: Re: Synchronized scans