Обсуждение: pgsql: pg_surgery: Try to stabilize regression tests.
pg_surgery: Try to stabilize regression tests. According to buildfarm member sungazer, the behavior of VACUUM can be unstable in these tests even if we prevent autovacuum from running on the tables in question, apparently because even a manual vacuum can behave differently depending on whether anything else is running that holds back the global xmin. So use a temporary table instead, which as of commit a7212be8b9e0885ee769e8c55f99ef742cda487b enables vacuuming using a more aggressive cutoff. This approach can't be used for the regression test that involves a materialized view, but that test doesn't run vacuum, so it shouldn't be prone to this particular failure mode. Analysis by Tom Lane. Patch by Ashutosh Sharma and me. Discussion: http://postgr.es/m/665524.1599948007@sss.pgh.pa.us Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/0811f766fd740018a72e222521553f8b22e7b3d6 Modified Files -------------- contrib/pg_surgery/expected/heap_surgery.out | 10 ++++------ contrib/pg_surgery/sql/heap_surgery.sql | 11 ++++------- 2 files changed, 8 insertions(+), 13 deletions(-)
On Fri, Sep 18, 2020 at 05:27:06PM +0000, Robert Haas wrote: > pg_surgery: Try to stabilize regression tests. > > According to buildfarm member sungazer, the behavior of VACUUM can be > unstable in these tests even if we prevent autovacuum from running on > the tables in question, apparently because even a manual vacuum can > behave differently depending on whether anything else is running that > holds back the global xmin. So use a temporary table instead, which > as of commit a7212be8b9e0885ee769e8c55f99ef742cda487b enables > vacuuming using a more aggressive cutoff. > > This approach can't be used for the regression test that involves a > materialized view, but that test doesn't run vacuum, so it shouldn't > be prone to this particular failure mode. > > Analysis by Tom Lane. Patch by Ashutosh Sharma and me. rorqual has just reported an issue here: https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=rorqual&dt=2020-09-20%2011%3A20%3A11 vacuum freeze htab2; +ERROR: cannot freeze committed xmax 23257 +CONTEXT: while scanning block 0 and offset 2 of relation "pg_temp_3.htab2" -- unused TIDs should be skipped select heap_force_kill('htab2'::regclass, ARRAY['(0, 2)']::tid[]); -NOTICE: skipping tid (0, 2) for relation "htab2" because it is marked unused -- Michael
Вложения
Michael Paquier <michael@paquier.xyz> writes:
> rorqual has just reported an issue here:
Already under discussion on the patch's main thread.
regards, tom lane