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 1oTHEd-0000cg-3w for pgsql-hackers@arkaria.postgresql.org; Wed, 31 Aug 2022 06:29:59 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1oTHDd-00035J-LB for pgsql-hackers@arkaria.postgresql.org; Wed, 31 Aug 2022 06:28:57 +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 1oTHDd-00035A-8w for pgsql-hackers@lists.postgresql.org; Wed, 31 Aug 2022 06:28:57 +0000 Received: from mail-pf1-x433.google.com ([2607:f8b0:4864:20::433]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1oTHDX-0008T5-2b for pgsql-hackers@lists.postgresql.org; Wed, 31 Aug 2022 06:28:56 +0000 Received: by mail-pf1-x433.google.com with SMTP id c66so3239607pfc.10 for ; Tue, 30 Aug 2022 23:28:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=j-davis-com.20210112.gappssmtp.com; s=20210112; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:from:to:cc; bh=oHsdC4Tugn72o/KCxmugF2o8ish+35vRX13PdqVo6v8=; b=xSjZA0ZBPg6cWM0q64ZGa/rz2dJis3hobUupE8WHBRBrYR+DZmz1OsIpN7YU/djgu7 +hrq6kNvC6qN9vwx5Gozt1wf+inbYJfkN//5c0ARAjc8X0df3yKcUzvdNpIXUzYBGtEV E468CYAQyq2aCg7d5HwxUgyOwCu3IEdLpfsAoVgARzwezMjWc7KczE1S7LqwcGpYEbT0 qcfWrmCc2jTDVyLw2oqM8vifMV5G8M0ntPWWtSRXBEF/wkq1QPRBl41A/UYL0t4YJYPC RKZP/Ts9R6EgAOD6n7NOg5L+/P6SXec3HieZ6XY/5JNdBJJL/HZT6WEc/lAMkhP83i5z xFxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:x-gm-message-state :from:to:cc; bh=oHsdC4Tugn72o/KCxmugF2o8ish+35vRX13PdqVo6v8=; b=au8wzOcyJ0aQm+PKUBcJDrCYQm9lIcqRQUqkOvnm0VeZZCUk/qtasKH+8DbB2YPpxQ I34UgslWU1M85QSMPg2JbpuyWfVHzoyI9kUnq/jYPX/ex5V894TB6AXMvdhX3eC8t1Qu W6VHS8pDEOVs+47HfwLcqnn+lxXw+qiMHDY+O4bfh+LkErHfaeImBizQXUba5QoBQF3l jzskdqhuDxLYFyrRGKR8mZFNZTMnse7PmB/18TWrLaK+u1HE0te501erPkB1V7fPvEEN 6Zp9TIUs5eoiSGRw0g4lyAjzBiwELEtWcdTdnMC6/dikp1hLs7IbFlyGdBW1EevExoEf BEQQ== X-Gm-Message-State: ACgBeo2ypFwo6LnaBHBZrVmixBNks3+QUXyb97yJNIbLbZVZ3K4GhRia Iylvj6xaCtyrbLHkJuoaryAs+A== X-Google-Smtp-Source: AA6agR4blZty3WhZrVliDtVZWzrQwuzGQiWoqRuGWu1qgw/7k9mBY1rhvieFS9jX8c3OQ5nTCxGydA== X-Received: by 2002:a63:5912:0:b0:42a:dcc6:210d with SMTP id n18-20020a635912000000b0042adcc6210dmr21628161pgb.50.1661927328374; Tue, 30 Aug 2022 23:28:48 -0700 (PDT) Received: from jeff-laptop.lan (c-73-231-146-4.hsd1.ca.comcast.net. [73.231.146.4]) by smtp.gmail.com with ESMTPSA id g8-20020a62f948000000b0053ab9c189e2sm692670pfm.2.2022.08.30.23.28.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 30 Aug 2022 23:28:48 -0700 (PDT) Message-ID: Subject: Re: New strategies for freezing, advancing relfrozenxid early From: Jeff Davis To: Peter Geoghegan Cc: PostgreSQL Hackers Date: Tue, 30 Aug 2022 23:28:46 -0700 In-Reply-To: References: <1892cc797f86924e31f00fd3c703ca464936c65e.camel@j-davis.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.44.1-0ubuntu1 MIME-Version: 1.0 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Tue, 2022-08-30 at 13:45 -0700, Peter Geoghegan wrote: > It's that I believe > that it is all but mandatory for me to ameliorate the downside that > goes with more eager freezing, for example by not doing it at all > when > it doesn't seem to make sense. I want to solve the big problem of > freeze debt, without creating any new problems. And if I should also > make things in adjacent areas better too, so much the better. That clarifies your point. It's still a challenge for me to reason about which of these potential new problems really need to be solved in v1, though. > Why stop at a couple of dozens of lines of code? Why not just change > the default of vacuum_freeze_min_age and > vacuum_multixact_freeze_min_age to 0? I don't think that would actually solve the unbounded buildup of unfrozen pages. It would still be possible for pages to be marked all visible before being frozen, and then end up being skipped until an aggressive vacuum is forced, right? Or did you mean vacuum_freeze_table_age? Regards, Jeff Davis