Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1uPhuj-00E5U8-4r for pgsql-general@arkaria.postgresql.org; Thu, 12 Jun 2025 13:24:17 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1uPhuh-00Cfaz-9F for pgsql-general@arkaria.postgresql.org; Thu, 12 Jun 2025 13:24:15 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1uPhug-00Cfaj-Ty for pgsql-general@lists.postgresql.org; Thu, 12 Jun 2025 13:24:15 +0000 Received: from mail-wm1-x32c.google.com ([2a00:1450:4864:20::32c]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1uPhuf-001bsW-1b for pgsql-general@lists.postgresql.org; Thu, 12 Jun 2025 13:24:14 +0000 Received: by mail-wm1-x32c.google.com with SMTP id 5b1f17b1804b1-450ce671a08so5533735e9.3 for ; Thu, 12 Jun 2025 06:24:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cybertec.at; s=google; t=1749734652; x=1750339452; darn=lists.postgresql.org; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:to:from:subject:message-id:from:to:cc:subject:date :message-id:reply-to; bh=XSw7Kx7ZU/4F51E6D/iIE38KrAoVP0w07LWgv4xPCiA=; b=e/uhCwnqOzwG1lMNq0hfWSeU1p+TgkEvWDuOnzfoLz4n4c/VeuW/3HcFt011867LjG LNqsd86JKLxtbcHeqYcUHL8APpJ18hD4MeXIgZHe/pdYIO08FBN/N5iYNDEot2snThBC EOdCE14TQqX+Zn56oir3Rtv+sWXSjXqtlVxNj1WOfvDyw7CcEMJrklkhQix9sbQwiS6Y 95Djg5A2YAY/sqEfvO5SUzoyVP5PP+HG4yf9eRC9ewr3B0A2jl0BpioIIC3jU9hCH0Pc /czDEB5nvWcec3UIT64gCIpDpJc/FnsfqEFBBKx4AuLwkX1bVHGLcx/GkO1RfGgz3vvi Y8Yw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1749734652; x=1750339452; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:to:from:subject:message-id:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=XSw7Kx7ZU/4F51E6D/iIE38KrAoVP0w07LWgv4xPCiA=; b=dltQKghZTf5qtTZFlGJGRG1iy18sJGASYrywoQGSNOs8z2beW9ioCNPExJ/kp47TEL 4JUSI8VbqHYROym02qSoEHTbvTgfQt/up4K4B846LrOKNeFKrOy9f4p9pViF9HnRHN2/ 8r3Ya8hHSBg6C87u/6jh6ZQ1AAGxlzqV8ugHHqcP0zc0VjrXbQRfBVeLm7Xv/VDvElcd JemL5rXVr5/87VlkOwS2VXl2o2viztM5SNFW67t3CiOOaTM39Snwnff8e1QUAcEsmoiR yecY7W5MQ4cFwAjRVJ0GH7nDTYBrIxmyz4z22mwYIWV/LBwRkS1NVnGMkt2TlnRVqZed 9hWw== X-Forwarded-Encrypted: i=1; AJvYcCWGf1t4TqlIInC984YrP7jGDfgmXeSj4rX+qg9EB7r7+wbN3QCn3zQ3GjYn1WDoiid8ATnb/AqraoINbTKU@lists.postgresql.org X-Gm-Message-State: AOJu0Yw9DKIgbznuCudRHf3gX2Hl7/M3AnIYpNlA1EwE5hVegMbLw0Jl 8PfOIxk6EvKGfwft+b2xwOTrXliiv1aI16GHDNgvGeHfjhCEXY2U2OgeLQM6G0eJg5Y= X-Gm-Gg: ASbGncvhT3vbiBV6vrgkMLDnLWeuSuOAI6+lVfgT7rX7Dgg5kimlOEjIJWC6dKxvRNS 6AkX4dzriFiMy04AOFFlq9oFYAkD/JyFr+vCpSHvD/Osz4Yb8nOYDOOD34EY3gccKQ+5ky+/dJt FfrXRH6m0or6ddQTZkqwMQmLnFZ6QOze7KEGNyC9IB2zue4U7ThEnvJRMBe3TBSgY6j5jlYC2mN 5OXP6Mw52YT27yQ0dOCOyXgysWtTvJ0juEvBhSHQa+xYSg50ywtHi3q0FVzN1IExHr89rcRwoqG ewDQjjDnWOTyXNbRNGEXcjJnnpI9bQPlVupoDRLLMvHnNofWDeelXJsZtGjc17fWd4IDoONPjmy JKUb23tu03iR788P3 X-Google-Smtp-Source: AGHT+IGO0mh7EsEPMNFkIj69ME+uo8oX92JfSKiqzxUS607/5ncTQvKulwN9AyxL1+8vwBAA+Z+BXg== X-Received: by 2002:a05:600c:5251:b0:450:cf46:5510 with SMTP id 5b1f17b1804b1-4532d31bfc7mr27524245e9.29.1749734651886; Thu, 12 Jun 2025 06:24:11 -0700 (PDT) Received: from laurenz.albe-K4N0CV00F97414D ([2001:871:260:ea3b:b7db:9841:e1cf:f924]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4532e16a097sm21104435e9.33.2025.06.12.06.24.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 12 Jun 2025 06:24:11 -0700 (PDT) Message-ID: <61b05ae722c2b21cd63d98544c55ecc0e35aa887.camel@cybertec.at> Subject: Re: db maintanance problem VACUUM FULL From: Laurenz Albe To: Pavol Sekeres , pgsql-general@lists.postgresql.org Date: Thu, 12 Jun 2025 15:24:11 +0200 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.56.2 (3.56.2-1.fc42) MIME-Version: 1.0 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Thu, 2025-06-12 at 15:14 +0200, Pavol Sekeres wrote: > We recently updated our production database to PostgreSQL 12.22 from the = 9.6.24 version. > We didn't want to make a big jump. But you should have. v12 is out of support. > It is around 2 TB in size with one stand-by replica of equal size. >=20 > We do run AUTOVACUUM processes on all tables periodically. > We have never run VACUUM FULL on any table. > This is because we can't afford to lock out tables for a long time. >=20 > Tables can be more than 100GB in size. > They are being updated daily. > Also due to GDPR old data is erased on a daily basis. > We think these tables might get eventually bloated. > > Can this be a problem? Yes. Check for bloat in suspicious tables using the "pgstattuple" extension. > If yes, is there any other solution outside locking the database? There are the third-party tools pg_squeeze and pg_repack. > Should we try to solve this problem by creating a logical replica of the = database? > We would then promote the replica to primary. > After that, we would drop the old database. > Is this possible without a big downtime? Yes, that is possible. > Is this even a good idea? Logical replication can be complicated. One of the above tools would be si= mpler. > Our database uses a wal_level 'replica'. > As I understand it, this setting would first have to be switched to 'logi= cal'. Right. Yours, Laurenz Albe