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 1mzj0C-0001Tb-HE for pgsql-hackers@arkaria.postgresql.org; Tue, 21 Dec 2021 17:32:40 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1mzj0B-0006hQ-BQ for pgsql-hackers@arkaria.postgresql.org; Tue, 21 Dec 2021 17:32:39 +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 1mzj0A-0006hG-Nn for pgsql-hackers@lists.postgresql.org; Tue, 21 Dec 2021 17:32:39 +0000 Received: from mail-oo1-xc32.google.com ([2607:f8b0:4864:20::c32]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1mzj07-0007JQ-77 for pgsql-hackers@lists.postgresql.org; Tue, 21 Dec 2021 17:32:37 +0000 Received: by mail-oo1-xc32.google.com with SMTP id v30-20020a4a315e000000b002c52d555875so4261994oog.12 for ; Tue, 21 Dec 2021 09:32:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=enterprisedb.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=YuCZmtl+LovlGF+uzvO2gL1SqtJVzEEs3Xj5w0+nwwY=; b=fdTO3zhLJifeUtPpMyXuFTkJdiTqUnwlFpTvdTQY9qjpQXdxFbhIu7+FOlbZC0oeDr /gs/LCCg223OjNeMAfWyCOgdD4cwD4uQB6GFd3A6ZyZ4gZZ0BCBu3x/7+/NMwXuU4C9P +HpxqOI2PLACwVhBBJwmrz4bGNLmj8MguIRRx6GLttEB1T2aK36MDQcU+4WCA9w2vYFq uNHbGU2dawwGkMHEoREY9EjWlLm3lWjyUM07PVsx1oX5hHaIUpPlMPcum3PUHw2klsUV hKt7/4JVuyOyVQGJTrT0WDCE7mfvvvzqkf4J195ynuJODcsH51lKLw7rfsvnVF+d3f5m d51w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=YuCZmtl+LovlGF+uzvO2gL1SqtJVzEEs3Xj5w0+nwwY=; b=LL8Asmx+HDcEp0qlrKgG2nJmCYbnMuu8OsOUxlaYARwkGB+6tFpUfHQcQjbT4xwEVm WKNJjy4tonMgrIG8Be4DSEfJkOSTpf1s/RCWBMoSYCxKqcyhVL1n6Jxb+sKGCeb/hDzR pK09AwDFRBa80S7oQg9/iBwWbNgUs+lF0+030Y3r/3KXa7XboPeTILnYdleV0cegTOjI alZio0R0OjaCZvPK6nb30B+OtKtlpybvb3aRDC7kVwPEpe7dnNgN0LcAUMSGtzK4aPpT 1hgESxF/QiaAbVHCAFwsy0CplX29C8iua/IN2Zj6bI/ai92pdUQ+JdNmbWXgNpSXVNtT BxJQ== X-Gm-Message-State: AOAM530Zci8wYeWAasU+bC9rhh0SsCYN+irqfVVXjFSMM0ISg59rJJYy eEbqMidlB1ykTlyfgcesqmNycIYM5YsPCkmsrjyPkzkGHYtsK5Ws0eTH5fvXJi0QHEhspjmJRjp qqMTdOfXWfIV1xCTgAV4IRv9OW252+oIvuEAhvL0UUcz5g3aVLc6R7ruUI7ly3U5YladbS48k14 Jf+Cl2WPa8nURTEd6qmoR8tvjJoH3BK8JqeZycp+/bDwX2q52jiCbdhkD8RIL0eWnvTcZohXx76 EST X-Google-Smtp-Source: ABdhPJzl+xqrj9lEKTmBrMbZjbUf11Avd6gTn7ofa0BXkklyfa89eqHLPYabMxagQlm902o9+cc7y3kRyc/6qqo1VLg= X-Received: by 2002:a4a:ead8:: with SMTP id s24mr2629602ooh.89.1640107954306; Tue, 21 Dec 2021 09:32:34 -0800 (PST) MIME-Version: 1.0 References: <3F7FD826-36EF-4991-AB37-81675AFEBF54@amazon.com> <0544901A-0FC5-46B5-801B-F30AC0B81A19@amazon.com> <20211221034630.maoteglpjqpgh62g@alap3.anarazel.de> In-Reply-To: From: John Naylor Date: Tue, 21 Dec 2021 13:36:20 -0400 Message-ID: Subject: Re: do only critical work during single-user vacuum? To: Masahiko Sawada Cc: Peter Geoghegan , Andres Freund , "Bossart, Nathan" , PostgreSQL Hackers Content-Type: text/plain; charset="UTF-8" X-CLOUD-SEC-AV-Info: enterprisedb,google_mail,monitor X-CLOUD-SEC-AV-Sent: true X-Gm-Spam: 0 X-Gm-Phishy: 0 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Tue, Dec 21, 2021 at 3:56 AM Masahiko Sawada wrote: > > On Tue, Dec 21, 2021 at 1:53 PM Peter Geoghegan wrote: > > > > On Mon, Dec 20, 2021 at 8:40 PM Masahiko Sawada wrote: > > > BTW a vacuum automatically enters failsafe mode under the situation > > > where the user has to run a vacuum in the single-user mode, right? > > > > Only for the table that had the problem. Maybe there are no other > > tables that a database level "VACUUM" will need to spend much time on, > > or maybe there are, and they will make it take much much longer (it > > all depends). > > > > The goal of the patch is to make sure that when we're in single user > > mode, we'll consistently trigger the failsafe, for every VACUUM > > against every table -- not just the table (or tables) whose > > relfrozenxid is very old. That's still naive, but much less naive than > > simply telling users to VACUUM the whole database in single user mode > > while vacuuming indexes, etc. > > I understand the patch, thank you for the explanation! > > I remember Simon proposed a VACUUM command option[1], called > FAST_FREEZE, to turn off index cleanup and heap truncation. Now that > we have failsafe mechanism probably we can have a VACUUM command > option to turn on failsafe mode instead. I've been thinking a bit more about this, and I see two desirable goals of anti-wraparound vacuum in single-user mode: 1. Get out of single-user mode as quickly as possible. 2. Minimize the catch-up work we have to do once we're out. Currently, a naive vacuum does as much work as possible and leaves a bunch of WAL streaming and archiving work for later, so that much is easy to improve upon and we don't have to be terribly sophisticated. Keeping in mind Andres' point that we don't want to force possibly unwanted behavior just because we're in single-user mode, it makes sense to have some kind of option that has the above two goals. Instead of a boolean, it seems like the new option should specify some age below which VACUUM will skip the table entirely, and above which will enter fail-safe mode. As mentioned earlier, the shutdown hint could spell out the exact command. With this design, it would specify the fail-safe default, or something else, to use with the option. That seems doable for v15 -- any thoughts on that approach? In standard operation, the above goals could be restated as "advance xmin as quickly as possible" and "generate as little future 'work/debt' as possible, whether dirty pages or WAL". There are some more sophisticated things we can do in this regard, but something like the above could also be useful in normal operation. In fact, that "normal" could be just after we restarted after doing the bare-minimum in single-user mode, and want to continue freezing and keep things under control. -- John Naylor EDB: http://www.enterprisedb.com