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

x4mmm@yandex-team.ru

From: "Andrey M. Borodin" <x4mmm@yandex-team.ru>
To: Ashutosh Sharma <ashu.coek88@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-28T08:22:47Z
Lists: pgsql-hackers

> 27 июля 2020 г., в 09:36, Ashutosh Sharma <ashu.coek88@gmail.com> написал(а):
> 
> > Also, should we try to fix VM along the way?
> 
> I think we should let VACUUM do that.
Sometimes VACUUM will not get to these pages, because they are marked All Frozen.
An possibly some tuples will get stale on this page again

> > Are there any caveats with concurrent VACUUM? (I do not see any, just asking)
> 
> As of now, I don't see any.
VACUUM has collection of dead item pointers. We will not resurrect any of them, right?

> > It would be good to have some checks for interrupts in safe places.
> 
> I think I have already added those wherever I felt it was required. If you feel it's missing somewhere, it could be good if you could point it out.
Sorry, I just overlooked that call, everything is fine here.

> > Also, I'd be happy if we had something like "Restore this tuple iff this does not break unique constraint". To do so we need to sort tids by xmin\xmax, to revive most recent data first.
> 
> I didn't get this point. Could you please elaborate. 
You may have 10 corrupted tuples for the same record, that was updated 9 times. And if you have unique constraint on the table you may want to have only latest version of the row. So you want to kill 9 tuples and freeze 1.

Thanks!

Best regards, Andrey Borodin.


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.