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 1tvEcu-002dcr-Je for pgsql-general@arkaria.postgresql.org; Thu, 20 Mar 2025 12:03:56 +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 1tvEct-0005X8-5T for pgsql-general@arkaria.postgresql.org; Thu, 20 Mar 2025 12:03:55 +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 1tvEcs-0005Wz-LA for pgsql-general@lists.postgresql.org; Thu, 20 Mar 2025 12:03:54 +0000 Received: from mail-oi1-x233.google.com ([2607:f8b0:4864:20::233]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1tvEcq-0007VV-2A for pgsql-general@lists.postgresql.org; Thu, 20 Mar 2025 12:03:53 +0000 Received: by mail-oi1-x233.google.com with SMTP id 5614622812f47-3fa6c54cc1aso450909b6e.1 for ; Thu, 20 Mar 2025 05:03:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1742472232; x=1743077032; darn=lists.postgresql.org; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=L7ljmwKJE4bILFBQCWv8LJXJtJ28vdfTkDJWdYoV1zo=; b=FmYwvZgIs2lmQnJ8oqwdsv/POXGWSfNX2QosYRhmpB2Agq+ncrqjP19YpdFAGakAMC EjymiB3cY1wwA4uaH3t2GHMEuexQLEL3YYigTp+MYhIifZrLCMQu9KlkVpI9sBKscycd 6JZz+KZNUiFjRAsKkd0kRD5NCUWq7DUQlivup5TzqIQXLYid2+kI966uS9eqx3+3/+ag L0nVcXPv0RYUk+R0e9HU4ecpkuoJdi4DlsTQ9agKUkLbQXeSxCbJnY4WMm3s8Q5FM+Ai kOd7qadX5QjJ0rPC4Cvtz5ijchqe3JNjNNfrcDBbZ14YaVP3NXlAvBoncqMzu9YF/Icf KVUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1742472232; x=1743077032; h=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=L7ljmwKJE4bILFBQCWv8LJXJtJ28vdfTkDJWdYoV1zo=; b=reNdnz7vYRzu9qiTen/MEG5kUYxpLstLa8eaUFwb3s5vzlT86KbO5E/CV4KC4FLQ3Z a4qR8p/8MYRlz3LQ5KJkBuzk+f4HLvDxFj07MnJ79WP4OhGZsuy/T+De/7KiYgRujWm9 6alDS1PMDtmoarDgpnCc1iCqJES19KRwerBk0w5sjAgiQQ2mmkWOs3In5jybJW3xV+he mFDj8wKHeoguz7aPCNT78svOlXe2tDdSf66QPI5RBux/EiFdqWJS6mXAioI04TZuf7r5 0E5dLrjRsCgsWxe1L6bx0qlIqOqqJLK7rSSD4Fgy3HBKrn/3dQJa4JA25P0TS+VnHeOi 1TCQ== X-Gm-Message-State: AOJu0Yz4LGCOKX8Y2B/ot28UfBiJg3UsGbKen2MWM1OdroZVKxmjmlax W2EskQRinp9Dx0u1W1XRSHabVB5jTD2lGyJvjNMtwrtwucKdihllRYGUdoYhFRsXqG+NQe5eJS+ lRibLMLiGXDqlJhXaJ91foBEcIT9P2j+4 X-Gm-Gg: ASbGncu1qFfHLj/DEUdcuLYWr7vteBTQnQYbsRJ95dQKZrvXkrdcjYi83CU+N5+Llrh iOqjfv9pB0a6yJ/GYzYB05foe8Bb5pqW8pI05ftkgLO5d0g9j5TNOFneUaOGQ/EHYOF/kM//mgM y3XRDRarIp2adLLYTvoXElQpNjanhKzxE3oKH1S65KcmCiP1rW8eZmtQkpbXHr X-Google-Smtp-Source: AGHT+IEvNv+7BpRWBdYP1Cd7XdJ8LyfjiYob0QA7p4wxAah0XaIiLIvtbG4YJV4wobVCkT4fFErXczdJdkAJm0mGtS4= X-Received: by 2002:a05:6808:f87:b0:3fc:219:c620 with SMTP id 5614622812f47-3fead592b74mr4551889b6e.23.1742472231489; Thu, 20 Mar 2025 05:03:51 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ron Johnson Date: Thu, 20 Mar 2025 08:03:40 -0400 X-Gm-Features: AQ5f1JpYwvn5B1c_krWkQR9yAqa8YSKrJYU15MI02aEOKirMITXfGVG00QXnLNo Message-ID: Subject: Re: Bloated toast table with empty associated table To: "pgsql-generallists.postgresql.org" Content-Type: multipart/alternative; boundary="000000000000639d7d0630c4ee39" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000639d7d0630c4ee39 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Mar 20, 2025 at 7:40=E2=80=AFAM Paul Allen w= rote: > 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 controlzone_passage". How often you run it depends on how quickly it bloats. --=20 Death to , and butter sauce. Don't boil me, I'm still alive. lobster! --000000000000639d7d0630c4ee39 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Mar 20, 2025 at 7:40=E2=80=AFAM P= aul Allen <paulcrtool@gmail.com<= /a>> 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=C2=A0 on
autovacuum_analyze_scale_factor=C2=A0 0.1
autovacuum_analyze_threshold=C2=A0 50
autovacuum_freeze_max_age=C2=A0 200000000
autovacuum_max_workers=C2=A0 3
autovacuum_multixact_freeze_max_age=C2=A0 400000000
autovacuum_naptime=C2=A0 60
autovacuum_vacuum_cost_delay=C2=A0 20
autovacuum_vacuum_cost_limit=C2=A0 -1
autovacuum_vacuum_scale_factor=C2=A0 0.2
autovacuum_vacuum_threshold=C2=A0 50
autovacuum_work_mem=C2=A0 -1
log_autovacuum_min_duration=C2=A0 -1

Yo= ur _scale_factor values are too high.=C2=A0 Drop them down to about 5%.

That's not the proximate cause, though.
=C2=A0
```

Problem.

My backend application attempts unsuccessfully repeatedly to insert the
same ~100 rows with images,

Instantaneously= and repeatedly, while ignoring the error?
=C2=A0
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=C2=A0 controlzone_passage".=C2=A0 How often you run it depends on how quickl= y it bloats.

--
Death to <Redacted>, and butter sauce.
Don't boil me, I'= ;m still alive.
<Redacted> lobster!
--000000000000639d7d0630c4ee39--