Re: recovering from "found xmin ... from before relfrozenxid ..."
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Ashutosh Sharma <ashu.coek88@gmail.com>
Cc: Robert Haas <robertmhaas@gmail.com>,
Mark Dilger <mark.dilger@enterprisedb.com>,
Masahiko Sawada <masahiko.sawada@2ndquadrant.com>,
"Andrey M. Borodin" <x4mmm@yandex-team.ru>,
MBeena Emerson <mbeena.emerson@gmail.com>,
PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>,
Andres Freund <andres@anarazel.de>,
Peter Eisentraut <peter.eisentraut@2ndquadrant.com>,
Stephen Frost <sfrost@snowman.net>
Date: 2020-09-16T03:44:38Z
Lists: pgsql-hackers
Ashutosh Sharma <ashu.coek88@gmail.com> writes: > On Wed, Sep 16, 2020 at 1:25 AM Tom Lane <tgl@sss.pgh.pa.us> wrote: >> * Should any of the other tables in the test be converted to temp? > Are you trying to say that we can achieve the things being done in > test-case 1 and 2 by having a single temp table and we should aim for > it because it will make the test-case more efficient and easy to > maintain? Well, I'm just looking at the comment that says the reason for the begin/rollback structure is to keep autovacuum's hands off the table. In most if not all of the other places where we need that, the preferred method is to make the table temp or mark it with (autovacuum = off). While this way isn't wrong exactly, nor inefficient, it does seem a little restrictive. For instance, you can't easily test cases that involve intentional errors. Another point is that we have a few optimizations that apply to tables created in the current transaction. I'm not sure whether any of them would fire in this test case, but if they do (now or in the future) that might mean you aren't testing the usual scenario for use of pg_surgery, which is surely not going to be a new-in-transaction table. (That might be an argument for preferring autovacuum = off over a temp table, too.) Like I said, I don't have a big problem with leaving the rest of the test as-is. It just seems to be doing things in an unusual way for no very good reason. regards, tom lane
Commits
-
Fix wrong data table horizon computation during backend startup.
- 1c7675a7a426 14.0 landed
-
Centralize horizon determination for temp tables, fixing bug due to skew.
- 94bc27b57680 14.0 landed
-
pg_surgery: Try to stabilize regression tests.
- 0811f766fd74 14.0 landed
-
New contrib module, pg_surgery, with heap surgery functions.
- 34a947ca13e5 14.0 landed
-
Set cutoff xmin more aggressively when vacuuming a temporary table.
- a7212be8b9e0 14.0 cited
-
snapshot scalability: Don't compute global horizons while building snapshots.
- dc7420c2c927 14.0 cited
-
Introduce vacuum errcontext to display additional information.
- b61d161c1463 13.0 cited