Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1ps19V-0007UD-Ci for pgsql-hackers@arkaria.postgresql.org; Thu, 27 Apr 2023 12:55:13 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1ps19U-00077c-1X for pgsql-hackers@arkaria.postgresql.org; Thu, 27 Apr 2023 12:55:12 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1ps19T-00077O-KU for pgsql-hackers@lists.postgresql.org; Thu, 27 Apr 2023 12:55:11 +0000 Received: from smtp.outgoing.loopia.se ([93.188.3.37]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1ps19L-002B1u-Ia for pgsql-hackers@postgresql.org; Thu, 27 Apr 2023 12:55:10 +0000 Received: from s807.loopia.se (localhost [127.0.0.1]) by s807.loopia.se (Postfix) with ESMTP id 512302F892E9 for ; Thu, 27 Apr 2023 14:55:00 +0200 (CEST) Received: from s981.loopia.se (unknown [172.22.191.5]) by s807.loopia.se (Postfix) with ESMTP id 2C5442E28738; Thu, 27 Apr 2023 14:55:00 +0200 (CEST) Received: from s898.loopia.se (unknown [172.22.191.6]) by s981.loopia.se (Postfix) with ESMTP id 14E6322B1759; Thu, 27 Apr 2023 14:54:59 +0200 (CEST) X-Virus-Scanned: amavisd-new at amavis.loopia.se X-Spam-Flag: NO X-Spam-Score: -1 X-Spam-Level: X-Spam-Status: No, score=-1 tagged_above=-999 required=6.2 tests=[ALL_TRUSTED=-1] autolearn=disabled Received: from s979.loopia.se ([172.22.191.5]) by s898.loopia.se (s898.loopia.se [172.22.190.17]) (amavisd-new, port 10024) with LMTP id ufI8le-6BnSw; Thu, 27 Apr 2023 14:54:58 +0200 (CEST) X-Loopia-Auth: user X-Loopia-User: daniel@yesql.se X-Loopia-Originating-IP: 89.255.232.193 Received: from smtpclient.apple (customer-89-255-232-193.stosn.net [89.255.232.193]) (Authenticated sender: daniel@yesql.se) by s979.loopia.se (Postfix) with ESMTPSA id 278EE10BC43E; Thu, 27 Apr 2023 14:54:58 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.2\)) Subject: Re: Should vacuum process config file reload more often From: Daniel Gustafsson In-Reply-To: Date: Thu, 27 Apr 2023 14:54:57 +0200 Cc: John Naylor , Melanie Plageman , Robert Haas , Andres Freund , Tom Lane , Kyotaro Horiguchi , PostgreSQL Hackers , Amit Kapila Content-Transfer-Encoding: quoted-printable Message-Id: References: <20230329.132155.629765142788133576.horikyota.ntt@gmail.com> <20230329.173456.1185961934810139447.horikyota.ntt@gmail.com> <935191FB-083B-4060-89FC-466F61FAA391@yesql.se> <1252075.1680547394@sss.pgh.pa.us> <20230403190837.qubpnwugfe2k2g46@awork3.anarazel.de> <7E06F879-7E20-4A6A-862F-CA72CDC9A323@yesql.se> <5028847C-937A-4CC2-B127-AFF5F9FB79C5@yesql.se> <2B703533-102A-47E5-A4F7-C6A68C09BB27@yesql.se> To: Masahiko Sawada X-Mailer: Apple Mail (2.3696.120.41.1.2) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk > On 27 Apr 2023, at 14:10, Masahiko Sawada = wrote: >=20 > On Thu, Apr 27, 2023 at 6:30=E2=80=AFPM John Naylor > wrote: >>=20 >>=20 >> On Fri, Apr 7, 2023 at 6:08=E2=80=AFAM Daniel Gustafsson = wrote: >>>=20 >>> I had another read-through and test-through of this version, and = have applied >>> it with some minor changes to comments and whitespace. Thanks for = the quick >>> turnaround times on reviews in this thread! >>=20 >> - VacuumFailsafeActive =3D false; >> + Assert(!VacuumFailsafeActive); >>=20 >> I can trigger this assert added in commit 7d71d3dd08. >>=20 >> First build with the patch in [1], then: >>=20 >> session 1: >>=20 >> CREATE EXTENSION xid_wraparound ; >>=20 >> CREATE TABLE autovacuum_disabled(id serial primary key, data text) = WITH (autovacuum_enabled=3Dfalse); >> INSERT INTO autovacuum_disabled(data) SELECT generate_series(1,1000); >>=20 >> -- I can trigger without this, but just make sure it doesn't get = vacuumed >> BEGIN; >> DELETE FROM autovacuum_disabled WHERE id % 2 =3D 0; >>=20 >> session 2: >>=20 >> -- get to failsafe limit >> SELECT consume_xids(1*1000*1000*1000); >> INSERT INTO autovacuum_disabled(data) SELECT 1; >> SELECT consume_xids(1*1000*1000*1000); >> INSERT INTO autovacuum_disabled(data) SELECT 1; >>=20 >> VACUUM autovacuum_disabled; >>=20 >> WARNING: cutoff for removing and freezing tuples is far in the past >> HINT: Close open transactions soon to avoid wraparound problems. >> You might also need to commit or roll back old prepared transactions, = or drop stale replication slots. >> WARNING: bypassing nonessential maintenance of table = "john.public.autovacuum_disabled" as a failsafe after 0 index scans >> DETAIL: The table's relfrozenxid or relminmxid is too far in the = past. >> HINT: Consider increasing configuration parameter = "maintenance_work_mem" or "autovacuum_work_mem". >> You might also need to consider other ways for VACUUM to keep up with = the allocation of transaction IDs. >> server closed the connection unexpectedly >>=20 >> #0 0x00007ff31f68ebec in __pthread_kill_implementation () >> from /lib64/libc.so.6 >> #1 0x00007ff31f63e956 in raise () from /lib64/libc.so.6 >> #2 0x00007ff31f6287f4 in abort () from /lib64/libc.so.6 >> #3 0x0000000000978032 in ExceptionalCondition ( >> conditionName=3DconditionName@entry=3D0xa4e970 = "!VacuumFailsafeActive", >> fileName=3DfileName@entry=3D0xa4da38 = "../src/backend/access/heap/vacuumlazy.c", = lineNumber=3DlineNumber@entry=3D392) at = ../src/backend/utils/error/assert.c:66 >> #4 0x000000000058c598 in heap_vacuum_rel (rel=3D0x7ff31d8a97d0, >> params=3D, bstrategy=3D) >> at ../src/backend/access/heap/vacuumlazy.c:392 >> #5 0x000000000069af1f in table_relation_vacuum (bstrategy=3D0x14ddca8,= >> params=3D0x7ffec28585f0, rel=3D0x7ff31d8a97d0) >> at ../src/include/access/tableam.h:1705 >> #6 vacuum_rel (relid=3Drelid@entry=3D16402, = relation=3Drelation@entry=3D0x0, >> params=3Dparams@entry=3D0x7ffec28585f0, = skip_privs=3Dskip_privs@entry=3Dtrue, >> bstrategy=3Dbstrategy@entry=3D0x14ddca8) >> at ../src/backend/commands/vacuum.c:2202 >> #7 0x000000000069b0e4 in vacuum_rel (relid=3D16398, = relation=3D, >> params=3Dparams@entry=3D0x7ffec2858850, = skip_privs=3Dskip_privs@entry=3Dfalse, >> bstrategy=3Dbstrategy@entry=3D0x14ddca8) >> at ../src/backend/commands/vacuum.c:2236 >=20 > Good catch. I think the problem is that vacuum_rel() is called > recursively and we don't reset VacuumFailsafeActive before vacuuming > the toast table. I think we should reset it in heap_vacuum_rel() > instead of Assert(). It's possible that we trigger the failsafe mode > only for either one.Please find the attached patch. Agreed, that matches my research and testing, I have the same diff here = and it passes testing and works as intended. This was briefly discussed in [0] = and slightly upthread from there but then missed. I will do some more = looking and testing but I'm fairly sure this is the right fix, so unless I find = something else I will go ahead with this. xid_wraparound is a really nifty testing tool. Very cool. -- Daniel Gustafsson [0] CAAKRu_b1HjGCTsFpUnmwLNS8NeXJ+JnrDLhT1osP+Gq9HCU+Rw@mail.gmail.com=