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 1tvEGe-002XzH-QV for pgsql-general@arkaria.postgresql.org; Thu, 20 Mar 2025 11:40: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 1tvEFf-002oqz-6N for pgsql-general@arkaria.postgresql.org; Thu, 20 Mar 2025 11:39:55 +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 1tvEFe-002oqr-RK for pgsql-general@lists.postgresql.org; Thu, 20 Mar 2025 11:39:54 +0000 Received: from mail-lf1-x136.google.com ([2a00:1450:4864:20::136]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1tvEFc-0007dl-1m for pgsql-general@lists.postgresql.org; Thu, 20 Mar 2025 11:39:54 +0000 Received: by mail-lf1-x136.google.com with SMTP id 2adb3069b0e04-54acc0cd458so880802e87.0 for ; Thu, 20 Mar 2025 04:39:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1742470791; x=1743075591; darn=lists.postgresql.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=P2QwQdodlRaV1E1Y2mqvUiUPeC61TUDmOcGpZOEnMUk=; b=ajbJ2E2wxd3hDr1l6TMpNYW87546nL/2cZJf+DurK6brD5qcx8oxtMUT4CW7tkwzoU cteep/S2QPEDeG36l6I3D500HBux0TDDoCwNwj0SiR95ev1+TtHSEKIUhla28BhNB7go ULFK7apDvmCud8Z/myODw4jvgDEqipRVrs4xI9wGhNZ9sKyjq0GrML0KfRHp//6Rg9Jy a8FaEqkMw8gApZzGUvycbqH3EgYdGywVxlzsoOvBhs53a2GvYRiGH/AgiPS7WwcKlxj9 QAXOFbGhnSWfCuRXfSMh4mJW5yFGAZ2tswmW2rc23bkye+HYbmltXme27AXQuF5xxvd+ yKAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1742470791; x=1743075591; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=P2QwQdodlRaV1E1Y2mqvUiUPeC61TUDmOcGpZOEnMUk=; b=b72SQ/jNSxqjyTnFrdJOJaCAiV8Omd4tK6MOxMRT25CNY/IhxPvr7aZKd2r5rikfc+ ocOQHBFWaXlaQ5XkgJ4NlISMvWae+kzLQNbR+GUn9Wclvx1zcnc8KMTe1JB4KCo9MQyi osD1/vcox0BLu6kt2+p5nsm0IvSE6oyAYLYdLpuvCNK46IVd4FNRKfeXT4K7fR/9kWU1 2XZ8INWpCKXBK6Xve5F6bWGvNcn/2/3opKWYbbf2P7PYYq071yh6/Ja+kgciZUfizzYu hnaHnWL8zDGmhYbxQqhqpSNQNSTJG67EZ7NJqhOczMrFtCoY7ExPPm8/SlJ4wSQTCzpA xwCg== X-Gm-Message-State: AOJu0Yx0yvMliLRaS5hnRlrEmdFOpJgGv6n2UXiDRchfsL5sVQXDPq+2 qH3tgPotIUR1xVpPQqYj8+BmanfSWds+adH2V4MHFFwv4dt24jl5+i5rm8WQ7M5TeJ/DND+zV+A HHSDyAb8zm/Mim69XB/3CXl5cUlqYvu1wpKFuFA== X-Gm-Gg: ASbGncujSdR296oljFO2Ue8JMkOSqgPkSCTB0acbK012PB+HbYYaX2A22ezZ6TJ8xv2 JY6+vfFcSEYQpv4KQEtqc72JRTtlwb3qe23X4LYRdvcFy/SftEsJRzoDzIWOsjm9oilagXCJg6I WssFTEJduyQJf/s4MiPGRapBkrLZpA4t+Oog== X-Google-Smtp-Source: AGHT+IHHVGnvmfqW+crnQ6CPIoDU6A1+wPUkZqwVVg8iT9sy+TXK479CZ9l7CN9DgYpRLGwunx3YqhCadWLMd4jV6UI= X-Received: by 2002:a05:6512:3da8:b0:549:5822:c334 with SMTP id 2adb3069b0e04-54acb21db2bmr2508972e87.52.1742470790730; Thu, 20 Mar 2025 04:39:50 -0700 (PDT) MIME-Version: 1.0 From: Paul Allen Date: Thu, 20 Mar 2025 15:39:39 +0400 X-Gm-Features: AQ5f1Jqg5BSsJp651OQBX7WQ7Oi3yceNEN5v4BcKParjznXg35R-7woKS-7bpew Message-ID: Subject: Bloated toast table with empty associated table To: pgsql-general@lists.postgresql.org Content-Type: text/plain; charset="UTF-8" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk 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 ``` Problem. My backend application attempts unsuccessfully repeatedly to insert the same ~100 rows with images, 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 = true, toast.autovacuum_enabled = true, autovacuum_vacuum_threshold = 0, toast.autovacuum_vacuum_threshold = 0, autovacuum_vacuum_scale_factor = 0, toast.autovacuum_vacuum_scale_factor = 0, autovacuum_analyze_threshold = 0, autovacuum_analyze_scale_factor = 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. Thanks. Daniil Rozanov