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 1mvViG-0000lx-5O for pgsql-hackers@arkaria.postgresql.org; Fri, 10 Dec 2021 02:32:44 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1mvViE-00066N-Cv for pgsql-hackers@arkaria.postgresql.org; Fri, 10 Dec 2021 02:32:42 +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 1mvViE-00066E-3p for pgsql-hackers@lists.postgresql.org; Fri, 10 Dec 2021 02:32:42 +0000 Received: from mail-ed1-x534.google.com ([2a00:1450:4864:20::534]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1mvViB-0006vS-Lb for pgsql-hackers@lists.postgresql.org; Fri, 10 Dec 2021 02:32:41 +0000 Received: by mail-ed1-x534.google.com with SMTP id e3so25945894edu.4 for ; Thu, 09 Dec 2021 18:32:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bowt-ie.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=qA8F4p/H2vTXsTI6cw3PE56g3JM2sbqGv6R+buh08Js=; b=UI6p3+bx9uV6fhFQWspYbA/8lZXINdu2v/Q4wz0JZ4Non/hodRI6Hw92VoKh7BF6Qc ws91LQRLk7DJgbma4ueCH6W/v6RfuwtggTNvZm5S5WOeEZ5NALfGegEkKnualPQkvuOl 0gvhqzXtN9uvIlRw5SUCEIUiB2vZoVog+NuN9P8DJH5yiEx42+ZVw3n1Fr8rqpQFrcNk YeWxcNoggmcsTeScGQknfZWKc3XV+zyZfMZ2deGAbK4Z+/NG4NRUITQk5dEgKSLLT01E X76vMrYpFfejqeCFwlqMxovyrI2N/jxSWUF9OoZG+y0kxSnbdqKweHnsu2KVCpH0F9ec Yf/g== 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=qA8F4p/H2vTXsTI6cw3PE56g3JM2sbqGv6R+buh08Js=; b=ZJzausHWGfQjMyg7fNsND+vYoAn1C7fTiHZluW1K8Bh++gJs6eBS16qOQn3N72sdny YHREZBJaPJVdxflK1w4ulGophmd2FmPqmn5PVoPLlFRU7srTpteEGObtkh+xsqwa36gy OO1d1SvBdgOV1xJiYAX9riq/vIj3Ox9pqwJjCRgjnU9zlx8I3sX+MV79iJehyGXfqRSQ 9LjCqpnHZhi+IdHPZElQmsqkLXMY2kOCoVNwIZFvSVNF+RkJYWQ4QBOeFGzxUMmMbLD4 tJWbxx1XyEEqOQeSqMzWbUhnXYzf3f0N4qzFOsLKOGVWk/wnjyOv+zJPECm+ImTa2bRJ Mddg== X-Gm-Message-State: AOAM533lMh4kyvUiO6coClq+e3i4Fpmiqb8xRgmEF/4GG+BgwhINkX9w axYN/T3pFGX+HW9dA5r0syM1cxJcg2b4xQk61jtBsQ== X-Google-Smtp-Source: ABdhPJzIT7FBwi+x+YYp+/NVK6Hru5L/yK5L06SX5WJrZI3Trl2J1hF9WbnRcYVQINQ2Xk/GMo0VsPx5mWX5xczBR0I= X-Received: by 2002:a50:e102:: with SMTP id h2mr33563810edl.298.1639103558703; Thu, 09 Dec 2021 18:32:38 -0800 (PST) MIME-Version: 1.0 References: <20211210015616.o242b4xchhpglfcy@alap3.anarazel.de> In-Reply-To: <20211210015616.o242b4xchhpglfcy@alap3.anarazel.de> From: Peter Geoghegan Date: Thu, 9 Dec 2021 18:32:12 -0800 Message-ID: Subject: Re: do only critical work during single-user vacuum? To: Andres Freund Cc: 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 5: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. I wouldn't say that this is moving closer to single user mode. > I don't think single user mode is a good fit for this anyway - it's inherently > focussed on connecting to a single database. But wraparound issues often > involve more than one database (often just because of shared catalogs). I don't disagree with any of that. My suggestions were based on the assumption that it might be unrealistic to expect somebody to spend a huge amount of time on this, given that (in a certain sense) it's never really supposed to be used. Even a very simple approach would be a big improvement. > Also, requiring a restart will often exascerbate the problem - the cache will > be cold, there's no walwriter, etc, making the vacuum slower. Making vacuum > not consume an xid seems like a lot more promising - and quite doable. Then > there's no need to restart at all. I didn't give too much consideration to what it would take to keep the system partially online, without introducing excessive complexity. Maybe it wouldn't be that hard to teach the system to stop allocating XIDs, while still allowing autovacuum workers to continue to get the system functioning again. With the av workers taking a particular emphasis on doing whatever work is required for the system to be able to allocate XIDs again -- but not too much more (not until things are back to normal). Now the plan is starting to get ambitious relative to how often it'll be seen by users, though. -- Peter Geoghegan