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 1nFgUh-0006PO-5x for pgsql-hackers@arkaria.postgresql.org; Thu, 03 Feb 2022 18:06:07 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nFgUg-0005m9-1h for pgsql-hackers@arkaria.postgresql.org; Thu, 03 Feb 2022 18:06:06 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nFgUf-0005lz-Ol for pgsql-hackers@lists.postgresql.org; Thu, 03 Feb 2022 18:06:05 +0000 Received: from mail-lf1-x130.google.com ([2a00:1450:4864:20::130]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1nFgUc-0004O2-Gj for pgsql-hackers@lists.postgresql.org; Thu, 03 Feb 2022 18:06:05 +0000 Received: by mail-lf1-x130.google.com with SMTP id z19so7594139lfq.13 for ; Thu, 03 Feb 2022 10:06:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=FixO4WwAJsa9Ft5hG1DRSnMc/nAdl6aqmKJzpij+LB8=; b=Pv3Yi3yZsfMEYt+3HvZRLitxRO4HMjm2/mAw7SQq0j5xZCc4xa9Ib9pCcArjRNv3Xf a1/y+XL4/a9WaFXtxuQtIYSbIWQUH/mtTl90vLJUae7YTRQStvBGPKFx8uEDgSETEdLw D55b1r4nHky3X9P3Ow3x8X4DiReBxGhpJ3b2o+62WKAyxcpM3W3OK1z1IQnqKweGwvDu 6ZSo5W0cRM63SPEXaZErD/hzDkKxlQUmNH1wbCoLCfSXlyW8EUHfeKK4P2dkCVc3oXxX vYEWK+1NgFhAnSj/2kmw/+uDaqaURLvej9ZKA6U2i8ZnpLXHZ3/33xc5M4mWu5xxC8lU 4Q5w== 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=FixO4WwAJsa9Ft5hG1DRSnMc/nAdl6aqmKJzpij+LB8=; b=qE8Krq3jgBk+Y41G7VFttXkQnQ5h9gqk9CyuZ1sOMXBS8KiVFOxLbQ73K20dqdH3kz mRyklbT1337MEZJvMnh0Ae+pVQMLF0E2kfkN+ojkc6wD/v6OqIAm3vsI0l7SvIPeIWEK bJNxXDDyaoF8/Yhzzyf7NZX2dSkEX7SyZj7hUD8gQhWWsIyHyecybZmrprZXmzGjMgSp kBjrJwX7qg3pOUTV6d6LPqmqWo9BUAV1/FX6L0kJ+Ax8UDnweSOTpXh920x4YRHnh/r7 TzgfR00xlreETiAq+sxoiukncT30oNnN+abdcz66As0GXMHxEMOzHtdQHKQ5bmBRpTyy 05jQ== X-Gm-Message-State: AOAM5302vHG9GyG7DUIb5OLP3m/eggExeDZ9BdsTKZFNLjxe4h2YrGdA 9bbNBzvPwe0xQqCLrn+IZB7mk14NWDKSFpPc0qg= X-Google-Smtp-Source: ABdhPJwSCx787OFV7HYhhtM1sQmVio6DONnfbLWGfhilsCFAuCNff1h6Kq/kS7OfUYrRtY2oLbrGJpKerLDv6HFHIw8= X-Received: by 2002:a05:6512:c19:: with SMTP id z25mr28169305lfu.675.1643911561111; Thu, 03 Feb 2022 10:06:01 -0800 (PST) MIME-Version: 1.0 References: <20211210015616.o242b4xchhpglfcy@alap3.anarazel.de> In-Reply-To: <20211210015616.o242b4xchhpglfcy@alap3.anarazel.de> From: Robert Haas Date: Thu, 3 Feb 2022 13:05:50 -0500 Message-ID: Subject: Re: do only critical work during single-user vacuum? To: Andres Freund Cc: Peter Geoghegan , John Naylor , PostgreSQL Hackers Content-Type: text/plain; charset="UTF-8" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Thu, Dec 9, 2021 at 8:56 PM Andres Freund wrote: > I think we should move *away* from single user mode, rather than the > opposite. It's a substantial code burden and it's hard to use. Yes. This thread seems to be largely devoted to the topic of making single-user vacuum work better, but I don't see anyone asking the question "why do we have a message that tells people to vacuum in single user mode in the first place?". It's basically bad advice, with one small exception that I'll talk about in a minute. Suppose we had a message in the tree that said "HINT: Consider angering a live anaconda to fix this problem." If that were so, the correct thing to do wouldn't be to add a section to our documentation explaining how to deal with angry anacondas. The correct thing to do would be to remove the hint as bad advice that we never should have offered in the first place. And so here. We should not try to make vacuum in single user-mode work better or differently, or at least that shouldn't be our primary objective. We should just stop telling people to do it. We should probably add messages and documentation *discouraging* the use of single user mode for recovering from wraparound trouble, exactly the opposite of what we do now. There's nothing we can do in single-user mode that we can't do equally well in multi-user mode. If people try to fix wraparound problems in multi-user mode, they still have read-only access to their database, they can use parallelism, they can use command line utilities like vacuumdb, and they can use psql which has line editing and allows remote access and is a way nicer user experience than running postgres --single. We need a really compelling reason to tell people to give up all those advantages, and there is no such reason. It makes just as much sense as telling people to deal with wraparound problems by angering a live anaconda. I did say there was an exception, and it's this: the last time I studied this issue back in 2019,[1] vacuum insisted on trying to truncate tables even when the system is in wraparound danger. Then it would fail, because truncating the table required allocating an XID, which would fail if we were short on XIDs. By putting the system in single user mode, you could continue to allocate XIDs and thus VACUUM would work. However, if you think about this for even 10 seconds, you can see that it's terrible. If we're so short of XIDs that we are scared to allocate them for fear of causing an actual wraparound, putting the system into a mode where that protection is bypassed is a super-terrible idea. People will be able to run vacuum, yes, but if they have too many tables, they will actually experience wraparound and thus data loss before they process all the tables they have. What we ought to do to solve this problem is NOT TRUNCATE when the number of remaining XIDs is small, so that we don't consume any of the remaining XIDs until we get the system out of wraparound danger. I think the "failsafe" stuff Peter added in v14 fixes that, though. If not, we should adjust it so it does. And then we should KILL WITH FIRE the message telling people to use single user mode -- and once we do that, the question of what the behavior ought to be when someone does run VACUUM in single user mode becomes a lot less important. This problem is basically self-inflicted. We have given people bad advice (use single user mode) and then they suffer when they take it. Ameliorating the suffering isn't the worst idea ever, but it's basically fixing the wrong problem. -- Robert Haas EDB: http://www.enterprisedb.com [1] http://postgr.es/m/CA+Tgmob1QCMJrHwRBK8HZtGsr+6cJANRQw2mEgJ9e=D+z7cOsw@mail.gmail.com