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 1nXyJ2-0002zF-O4 for pgsql-admin@arkaria.postgresql.org; Sat, 26 Mar 2022 04:45: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 1nXyJ1-0000UL-58 for pgsql-admin@arkaria.postgresql.org; Sat, 26 Mar 2022 04:45:39 +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 1nXyJ0-0000UC-Or for pgsql-admin@lists.postgresql.org; Sat, 26 Mar 2022 04:45:38 +0000 Received: from mail-oi1-x231.google.com ([2607:f8b0:4864:20::231]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1nXyIx-0001od-CU for pgsql-admin@lists.postgresql.org; Sat, 26 Mar 2022 04:45:37 +0000 Received: by mail-oi1-x231.google.com with SMTP id 12so10324852oix.12 for ; Fri, 25 Mar 2022 21:45:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :references:from:in-reply-to:content-transfer-encoding; bh=dPrkzJWCxPUvwnFJEVDA/GSoUTYfwAAuDZwSfNghRtE=; b=jP02X5qLvmyMNwHhKDbPsNKmJDkLZeyQ/3K6g7vB5+pb3bWoqrCtwwDCVoZVtJ0yRg 9hvQ7mP8KIxfSkJ0nq5qvMXQP6oqNTzSvs024faktp7dOF6aPIajMo0F+SULgf5TS4W8 mRkHSaJovbioRwd3XAogFWdLuNpl1vMgIfJ2j7G+jP02Xv1Uk4zDoazAjw3QXMCOhAQ4 K/RxsqlQtophwsrLRvqSz8TSB2FrHv4PZsHuMWTTU0uVzRKC7mGTAMAbIC5Lft1k3uVx 1p53RXvoFD6wNci0RZZThF4x6b6s0pGq+1INwI13JjKWdXl78lyyEcfpp7tGO+9iP1Ar 6Fjg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:references:from:in-reply-to :content-transfer-encoding; bh=dPrkzJWCxPUvwnFJEVDA/GSoUTYfwAAuDZwSfNghRtE=; b=Kss4ITtUn/KawwwNnpyrqn/F36WhRx8OcEbd8gRRKXQ808JIkVXaX4sMsFBK1NsaC2 irKqwUIL7rsdZeeEhVDA/kG7H3gVNEazQCcWrL71JUPv3uCBS3m8h6tiI1dVfnjePIux 5oqY4bs35znCaWu4NO2QMhwxU5hmF0CbFXLV4L8ABMhT20CDlB+gAUzNCxTolSS8/u3+ YNLQDgE1B/IpSPJxRz6yYi0l/vxJd4yPZkMf9bDg/Moc54iI/tN2YEfbak6Gm9TGSqOD 8/6kPBlX46dQrkc71pynZyo88MPeHOy7e7JhgYRHBN8yb3pTu5R6uMSurXWVU4pgfuiZ JLaw== X-Gm-Message-State: AOAM533zShyxzSaWDakFMCzYDAHkE5us8hz7yAaqVpUImjtQ37Pc/do7 BCqvFIQ42gKBD/EPSPDIVK0bvzJAt5U= X-Google-Smtp-Source: ABdhPJxFfnFibjNeQrgUtvLYKan3hoylVU/sA/KorQFA2KJaC4CQGH7XlbggUpoBrCx1OqxoFkA96A== X-Received: by 2002:a05:6808:210b:b0:2d9:a6d3:b029 with SMTP id r11-20020a056808210b00b002d9a6d3b029mr7255780oiw.182.1648269933034; Fri, 25 Mar 2022 21:45:33 -0700 (PDT) Received: from [192.168.88.10] (ip68-11-68-85.no.no.cox.net. [68.11.68.85]) by smtp.googlemail.com with ESMTPSA id n124-20020aca4082000000b002ecd08d8497sm3861266oia.5.2022.03.25.21.45.32 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 25 Mar 2022 21:45:32 -0700 (PDT) Message-ID: Date: Fri, 25 Mar 2022 23:45:31 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Subject: Re: Avoid Wraparound Failures Content-Language: en-US To: pgsql-admin@lists.postgresql.org References: <965a52fe849ec6e5759d349b4063b5077353f24b.camel@cybertec.at> From: Ron In-Reply-To: <965a52fe849ec6e5759d349b4063b5077353f24b.camel@cybertec.at> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 3/25/22 23:34, Laurenz Albe wrote: > On Fri, 2022-03-25 at 23:16 +0100, Loles wrote: >> Suppose the databases on my instance are near to have a wraparound failure. >> >> (I think so, from what I see, but in the PostgreSQL log I haven't seen any warning about It yet). >> >> What do I have to do? >> >> vacuum freeze; >> >> better than, >> >> vacuum analyze; >> >> Or both? >> >> If the autovacuum_freeze configuration parameters have defaults values, should I modify any first? >> >> More I read of this topic, more confused I am. >> >> Please, I need simple and wise advice :) > DON'T PANIC > > If what you see is the age of your oldest unfrozen rows approaching 200 million, > everything is just normal. That's when anti-wraparound autovacuum *begins*. > > Normally, you have nothing to do, except perhaps make sure than autovacuum is > fast enough (autovacuum_vacuum_cost_delay = 2). > > If you want to prevent that autovacuum run from happening while your system is > busy (which normally also is no problem), you can trigger a manual VACUUM at > a time of lower database activity. But make it a plain VACUUM, not a > VACUUM (FREEZE) Why not VACUUM FREEZE? > or (god forbid) VACUUM (FULL), and only VACUUM those tables > that are large and approaching the threshold. And don't VACUUM them all at the > same time. > > Yours, > Laurenz Albe -- Angular momentum makes the world go 'round.