Re: recovering from "found xmin ... from before relfrozenxid ..."

Ashutosh Sharma <ashu.coek88@gmail.com>

From: Ashutosh Sharma <ashu.coek88@gmail.com>
To: MBeena Emerson <mbeena.emerson@gmail.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Andres Freund <andres@anarazel.de>, Peter Eisentraut <peter.eisentraut@2ndquadrant.com>, Tom Lane <tgl@sss.pgh.pa.us>, Stephen Frost <sfrost@snowman.net>, Robert Haas <robertmhaas@gmail.com>
Date: 2020-07-29T04:37:49Z
Lists: pgsql-hackers
Hi Beena,

Thanks for the review.

1. We would be marking buffer dirty and writing wal even if we have
> not done any changes( ex if we pass invalid/dead tids). Maybe we can
> handle this better?
>

Yeah, we can skip this when nothing has changed. Will take care of it in
the next version of patch.


> cosmetic changes
> 1. Maybe "HTupleSurgicalOption" instead of "HTupleForceOption" and
> also the variable names could use surgery instead.
>

I think that looks fine. I would rather prefer the word "Force" just
because all the enum options contain the word "Force" in it.


> 2. extension comment pg_surgery.control "extension to perform surgery
> the damaged heap table" -> "extension to perform surgery on the
> damaged heap table"
>

Okay, will fix that typo.

--
With Regards,
Ashutosh Sharma
EnterpriseDB:http://www.enterprisedb.com

Commits

  1. Fix wrong data table horizon computation during backend startup.

  2. Centralize horizon determination for temp tables, fixing bug due to skew.

  3. pg_surgery: Try to stabilize regression tests.

  4. New contrib module, pg_surgery, with heap surgery functions.

  5. Set cutoff xmin more aggressively when vacuuming a temporary table.

  6. snapshot scalability: Don't compute global horizons while building snapshots.

  7. Introduce vacuum errcontext to display additional information.