public inbox for [email protected]
help / color / mirror / Atom feedFrom: Masahiko Sawada <[email protected]>
To: John Naylor <[email protected]>
Cc: Daniel Gustafsson <[email protected]>
Cc: Melanie Plageman <[email protected]>
Cc: Robert Haas <[email protected]>
Cc: Andres Freund <[email protected]>
Cc: Tom Lane <[email protected]>
Cc: Kyotaro Horiguchi <[email protected]>
Cc: PostgreSQL Hackers <[email protected]>
Cc: Amit Kapila <[email protected]>
Subject: Re: Should vacuum process config file reload more often
Date: Thu, 27 Apr 2023 21:10:00 +0900
Message-ID: <CAD21AoB_NQwdznBqcTMPv=vx71feDvBTNEMAvaUMAGqNcruk9Q@mail.gmail.com> (raw)
In-Reply-To: <CAFBsxsFz=GqaG5Ens5aNgVYoV2Y+pfMUijX0ku+CCkWfALwiqg@mail.gmail.com>
References: <[email protected]>
<[email protected]>
<CAAKRu_Yg4-kWH_EN7wtpm3z9B+H27UTmOxzzYv1Vg=YdZ6v_rw@mail.gmail.com>
<CAD21AoCGdxYAJHmE_nXw_MFw1+Qtn3vcThRu5FiadukgQnpWeQ@mail.gmail.com>
<[email protected]>
<CAAKRu_aoa0YT36q2n3xa9MZYdepeH4Jyf2EVJj=7YdC_1c974Q@mail.gmail.com>
<CAAKRu_bSsChKsyEy1ZV2XJQ22FoDdA56efjNr9==m2TO94557w@mail.gmail.com>
<CAD21AoDi4i4tj1Cf9BG0q2iyVhHisQ2xxVBZajEqExX6t6_b3g@mail.gmail.com>
<CAAKRu_bkg+0WAGTxsy0HP75RzFbPwqz3ctYq1kThjFhSL69upw@mail.gmail.com>
<[email protected]>
<[email protected]>
<CAAKRu_ap7nhmqtKQ1TRo3LzHG3FK=YpGO=O0019M3BbN7ysm3A@mail.gmail.com>
<[email protected]>
<CAAKRu_b1HjGCTsFpUnmwLNS8NeXJ+JnrDLhT1osP+Gq9HCU+Rw@mail.gmail.com>
<[email protected]>
<CAAKRu_bJ2DJxYoMkyMo9UpoX74LY5d2Jir86QWFUftrGKWP5Bw@mail.gmail.com>
<CA+TgmoYDYHht9zsHye3tywx7oWGMP4s_6AGefHkDsMuGHLzT7w@mail.gmail.com>
<CAAKRu_auVL_uE794zwiX6t18LJvKtJ5mrmV9tkbpWzS8AYeChQ@mail.gmail.com>
<CAAKRu_aX+MLn32kPnAQ30WChbiLTkKKmY9e8+B1ZY1BokpQZYA@mail.gmail.com>
<CAAKRu_aH-UbvNCQq-EouNUTjtGexQTRVo7ik_vYR4WUocVny7w@mail.gmail.com>
<CA+TgmoY3EaCz3_7F3+Sb3FUHonf4nxdC-_UWnn6fWEPtXU7t5g@mail.gmail.com>
<[email protected]>
<CAAKRu_YmQg_i=0DBfPzy1MMc2GjfuJFo=0rFv4fCzRQStLhjvw@mail.gmail.com>
<CAAKRu_beQECOV4WfU6nG0hhEVobCnH88Y8MQi1LrTwMfRyxuCw@mail.gmail.com>
<[email protected]>
<CAAKRu_Znk6WCCQqEw8hv3+X1Fm8gG0x4KKRAkKmO2JOcA-77-g@mail.gmail.com>
<[email protected]>
<CAFBsxsFz=GqaG5Ens5aNgVYoV2Y+pfMUijX0ku+CCkWfALwiqg@mail.gmail.com>
On Thu, Apr 27, 2023 at 6:30 PM John Naylor
<[email protected]> wrote:
>
>
> On Fri, Apr 7, 2023 at 6:08 AM Daniel Gustafsson <[email protected]> wrote:
> >
> > 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!
>
> - VacuumFailsafeActive = false;
> + Assert(!VacuumFailsafeActive);
>
> I can trigger this assert added in commit 7d71d3dd08.
>
> First build with the patch in [1], then:
>
> session 1:
>
> CREATE EXTENSION xid_wraparound ;
>
> CREATE TABLE autovacuum_disabled(id serial primary key, data text) WITH (autovacuum_enabled=false);
> INSERT INTO autovacuum_disabled(data) SELECT generate_series(1,1000);
>
> -- I can trigger without this, but just make sure it doesn't get vacuumed
> BEGIN;
> DELETE FROM autovacuum_disabled WHERE id % 2 = 0;
>
> session 2:
>
> -- 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;
>
> VACUUM autovacuum_disabled;
>
> 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
>
> #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=conditionName@entry=0xa4e970 "!VacuumFailsafeActive",
> fileName=fileName@entry=0xa4da38 "../src/backend/access/heap/vacuumlazy.c", lineNumber=lineNumber@entry=392) at ../src/backend/utils/error/assert.c:66
> #4 0x000000000058c598 in heap_vacuum_rel (rel=0x7ff31d8a97d0,
> params=<optimized out>, bstrategy=<optimized out>)
> at ../src/backend/access/heap/vacuumlazy.c:392
> #5 0x000000000069af1f in table_relation_vacuum (bstrategy=0x14ddca8,
> params=0x7ffec28585f0, rel=0x7ff31d8a97d0)
> at ../src/include/access/tableam.h:1705
> #6 vacuum_rel (relid=relid@entry=16402, relation=relation@entry=0x0,
> params=params@entry=0x7ffec28585f0, skip_privs=skip_privs@entry=true,
> bstrategy=bstrategy@entry=0x14ddca8)
> at ../src/backend/commands/vacuum.c:2202
> #7 0x000000000069b0e4 in vacuum_rel (relid=16398, relation=<optimized out>,
> params=params@entry=0x7ffec2858850, skip_privs=skip_privs@entry=false,
> bstrategy=bstrategy@entry=0x14ddca8)
> at ../src/backend/commands/vacuum.c:2236
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.
Regards,
--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com
Attachments:
[application/octet-stream] reset_VacuumFailsafeActive.patch (628B, ../CAD21AoB_NQwdznBqcTMPv=vx71feDvBTNEMAvaUMAGqNcruk9Q@mail.gmail.com/2-reset_VacuumFailsafeActive.patch)
download | inline diff:
diff --git a/src/backend/access/heap/vacuumlazy.c b/src/backend/access/heap/vacuumlazy.c
index 0a9ebd22bd..2ba85bd3d6 100644
--- a/src/backend/access/heap/vacuumlazy.c
+++ b/src/backend/access/heap/vacuumlazy.c
@@ -389,7 +389,7 @@ heap_vacuum_rel(Relation rel, VacuumParams *params,
Assert(params->index_cleanup != VACOPTVALUE_UNSPECIFIED);
Assert(params->truncate != VACOPTVALUE_UNSPECIFIED &&
params->truncate != VACOPTVALUE_AUTO);
- Assert(!VacuumFailsafeActive);
+ VacuumFailsafeActive = false;
vacrel->consider_bypass_optimization = true;
vacrel->do_index_vacuuming = true;
vacrel->do_index_cleanup = true;
view thread (26+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: Should vacuum process config file reload more often
In-Reply-To: <CAD21AoB_NQwdznBqcTMPv=vx71feDvBTNEMAvaUMAGqNcruk9Q@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox