Horton

Re: A design for amcheck heapam verification

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Peter Geoghegan <pg@bowt.ie>
Cc: PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2017-05-02T01:20:16Z
Lists: pgsql-hackers 
Peter Geoghegan <pg@bowt.ie> writes:
> If it's not clear what I mean: existing code that cares about
> RecentGlobalXmin is using it as a *conservative* point before which
> every snapshot sees every transaction as committed/aborted (and
> therefore nobody can care if that other backend hot prunes dead tuples
> from before then, or whatever it is). Whereas, amcheck needs to care
> about the possibility that *anyone else* decided that pruning or
> whatever is okay, based on generic criteria, and not what amcheck
> happened to see as RecentGlobalXmin during snapshot acquisition.

ISTM if you want to do that you have an inherent race condition.
That is, no matter what you do, the moment after you look the currently
oldest open transaction could commit, allowing some other session's
view of RecentGlobalXmin to move past what you think it is, so that
that session could start pruning stuff.

Maybe you can fix this by assuming that your own session's advertised xmin
is a safe upper bound on everybody else's RecentGlobalXmin.  But I'm not
sure if that rule does what you want.

			regards, tom lane

Commits

  1. Fix non-portable use of round().

  2. Add amcheck verification of heap relations belonging to btree indexes.

  3. Add Bloom filter implementation.

  4. Use ereport not elog for some corrupt-HOT-chain reports.

  5. Introduce 64-bit hash functions with a 64-bit seed.

  6. Upgrade src/port/rint.c to be POSIX-compliant.

  7. Use type "int64" for memory accounting in tuplesort.c/tuplestore.c.