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 1tvEuc-002fp7-S8 for pgsql-general@arkaria.postgresql.org; Thu, 20 Mar 2025 12:22:14 +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 1tvEub-000GNf-Js for pgsql-general@arkaria.postgresql.org; Thu, 20 Mar 2025 12:22:13 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tvEub-000GLB-8t for pgsql-general@lists.postgresql.org; Thu, 20 Mar 2025 12:22:13 +0000 Received: from mail-lj1-x22d.google.com ([2a00:1450:4864:20::22d]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1tvEuZ-00087f-0u for pgsql-general@lists.postgresql.org; Thu, 20 Mar 2025 12:22:12 +0000 Received: by mail-lj1-x22d.google.com with SMTP id 38308e7fff4ca-30613802a04so8034801fa.2 for ; Thu, 20 Mar 2025 05:22:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1742473329; x=1743078129; darn=lists.postgresql.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=wuZPc0loDJOoQYjJyMkqHdh9KTOxG57ZyhDTke8oRsY=; b=mg6izSqLfjWa/fSb4lwp9vJqLEu9bzAxU20V39ffUOqMEXiV4KrUDH/1MZwJ4PP673 woMWAYT1ePeMqS/O662y3V61gliQUrDYj61ZmOioFtqjr+xvfd4huQ7+RFcKwxvEliVu hvtRCj9MohCiIRDPw3/iog7vdrRg3tf2U4IeB+8XeKQ5PyJgstSCSA8mccPta7tZV7IS QWFDhvTGyx8ksjB2conpWthj4FkgnsALBpRBWB6ipCbRdVKf7WvcanEehUQsc6vKisDl G4Y2jkVa+oZW2sjcKp4G1IKiHKe0+ReMGFwEiVSbfO7mNuaGgh4xt2IYqZ8N/e73ny7/ dd9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1742473329; x=1743078129; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=wuZPc0loDJOoQYjJyMkqHdh9KTOxG57ZyhDTke8oRsY=; b=N1wVMf4P+FkWU+fM3MLdemog1f9w/fuTetnsrvmatn2vVR7PrDEw0PAZpiQb28Q84D GBZ9KbjanBMfRwPCeKD/k7w+BmM9WJRUQpvbRBvDbq9afxHYn+OHB85pQ5c0fFqNz2Lx 1propmGN64xcg4k1mwWX/kVtP2WFNggDiuyNVBW8I+9nvuHVteAakCtZ4yF0vW42KYid +h5jmngj714V8gdarmk1tNDzApfSrG9p9DxMMGky1YFI6HNvSrTDjqDzz4t98GYA8GZe qwxn/wMuABgPAzJDDm0maBbO43QFRm1DIIUS5JQgQYdk4yo42XVZ3OAMlY8e4DPbS4xS HNOQ== X-Gm-Message-State: AOJu0YzaYr5U9Y/RxaZL4dRfdfl9QWolWV3b7/ZQHAfntWEBdrC7Q/PK 4XOlt8Io4ZwkTp2y/N7/sf6C4PcUgoz/eZUt4CxsWYlsx7wKe4ay1AgLc3hZ58GAmEjbBvoSt8i e99mtFDKzEllm0cJtZ3YrMmi1CF4= X-Gm-Gg: ASbGncvtUpmxtwFaojs8AUv6T8uFM275HgOmg3VRtDHprmNf0/vi3uRBSOC3swrPqye icb4Z2k1RTJmqx4uMwagIj0+aFeQV7OsoZOE/Wgqq0bQ5wHrHAJviJO87pKD3WYTWrG6IDd1yWd o/IEJRmD3BGICJWH0DtnwRJUDXj/JVylzZ8g== X-Google-Smtp-Source: AGHT+IH/KqwxaUzOJVUL+aE47uhg65wEiss7+25oY5yQfnhJ1m9vMhsNb6fXt/Nb+FSbKL+wQcsnCgsqp6+z6aOW6sw= X-Received: by 2002:a05:651c:a0b:b0:30b:c3ce:ea1f with SMTP id 38308e7fff4ca-30d6a3e5ad7mr28877911fa.15.1742473328743; Thu, 20 Mar 2025 05:22:08 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Paul Allen Date: Thu, 20 Mar 2025 16:21:57 +0400 X-Gm-Features: AQ5f1JpPJX_UeFYDI4iNVS3Y7rHJM-PVnowfWt66rLsuvacqYz0-urIZoiRi1bQ Message-ID: Subject: Re: Bloated toast table with empty associated table To: Ron Johnson Cc: "pgsql-generallists.postgresql.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk > Instantaneously and repeatedly, while ignoring the error? Yes, that's how it should work and I probably can't do anything about it. > Your _scale_factor values are too high. Drop them down to about 5%. Okay, but what about altering controlzone_passage table, where I set all _scale_factor values to 0? If this did not have an effect, then how will the value of 5% affect? Maybe I misunderstand, but the table does not change by any number of rows and its logical size remains zero. Anyway I will try it. > I'd create a cron entry that does a regular "vacuumdb -d the_db -t contr= olzone_passage". How often you run it depends on how quickly it bloats. Seems like it is the only solution for now. On Thu, Mar 20, 2025 at 4:03=E2=80=AFPM Ron Johnson wrote: > > On Thu, Mar 20, 2025 at 7:40=E2=80=AFAM Paul Allen = wrote: >> >> Hello. >> >> Preconditions. >> >> I have some empty table and constantly try to execute `insert ... on >> conflict do update ...` on it. My data in row which I try to insert is >> invalid by violation of foreing key constraint, so I am getting error >> while inserting and table keeps being empty. This table have some bytea >> columns with default storage type. It's purpose is to keep images. >> PostgreSQL version is 15, everything is default, autovacuum settings is >> >> ``` >> autovacuum on >> autovacuum_analyze_scale_factor 0.1 >> autovacuum_analyze_threshold 50 >> autovacuum_freeze_max_age 200000000 >> autovacuum_max_workers 3 >> autovacuum_multixact_freeze_max_age 400000000 >> autovacuum_naptime 60 >> autovacuum_vacuum_cost_delay 20 >> autovacuum_vacuum_cost_limit -1 >> autovacuum_vacuum_scale_factor 0.2 >> autovacuum_vacuum_threshold 50 >> autovacuum_work_mem -1 >> log_autovacuum_min_duration -1 > > > Your _scale_factor values are too high. Drop them down to about 5%. > > That's not the proximate cause, though. > >> >> ``` >> >> Problem. >> >> My backend application attempts unsuccessfully repeatedly to insert the >> same ~100 rows with images, > > > Instantaneously and repeatedly, while ignoring the error? > >> >> and despite table's row count remains 0, >> toast table's size is growing up permanently, reaching 100, 200, 300 GB >> until it takes all available space. >> >> VACUUM FULL fixes this, but a want some automatic solution. I tried to >> alter table, believing that the settings below would force autovacuum to >> clean toast anyway, but it had no effect. >> >> ``` >> alter table controlzone_passage set ( >> autovacuum_enabled =3D true, >> toast.autovacuum_enabled =3D true, >> autovacuum_vacuum_threshold =3D 0, >> toast.autovacuum_vacuum_threshold =3D 0, >> autovacuum_vacuum_scale_factor =3D 0, >> toast.autovacuum_vacuum_scale_factor =3D 0, >> autovacuum_analyze_threshold =3D 0, >> autovacuum_analyze_scale_factor =3D 0); >> ``` >> >> At the moment, my assumption is that the autovacuum is not working >> because the number of rows in the table does not change and remains >> zero. Any solution will suit me, for example, not to write rows to toast >> if their insertion failed. Or the proper setting of the autovacuum. >> Please tell me what can be done. > > > I'd create a cron entry that does a regular "vacuumdb -d the_db -t contr= olzone_passage". How often you run it depends on how quickly it bloats. > > -- > Death to , and butter sauce. > Don't boil me, I'm still alive. > lobster!