Received: from [217.196.149.56] (helo=malur.postgresql.org) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sVIzo-009AZT-Nf for pgsql-general@arkaria.postgresql.org; Sat, 20 Jul 2024 22:56:24 +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 1sVIqF-003531-Gn for pgsql-general@arkaria.postgresql.org; Sat, 20 Jul 2024 22:46:15 +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 <01010190d2526ef9-5d0a93fe-30ad-4d6b-9bc8-269c188bd42e-000000@us-west-2.amazonses.com>) id 1sVIqF-00352t-1L for pgsql-general@lists.postgresql.org; Sat, 20 Jul 2024 22:46:15 +0000 Received: from a27-28.smtp-out.us-west-2.amazonses.com ([54.240.27.28]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from <01010190d2526ef9-5d0a93fe-30ad-4d6b-9bc8-269c188bd42e-000000@us-west-2.amazonses.com>) id 1sVIq9-000cJi-Rc for pgsql-general@postgresql.org; Sat, 20 Jul 2024 22:46:14 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=gfqkzvqjqro6qqm4n6msf2jnfycu5fci; d=thewickedtribe.net; t=1721515536; h=Subject:From:To:Date:Mime-Version:Content-Type:References:Message-Id; bh=yYQM4ZlR2h5xiG/S/D1WFz4lnQGIBp5tBUnY89XyaLU=; b=I4GF92VgS9bCANsAYF2JiMlAENZ+eVvn9BsmLBO49sFKIGXCmktKuPEIuClivscm hV6siPJw/BjzJFgRyBmJY8DW02IccfLRRfBPl4xKkuMwPlHaV5BSCIEaHtpPH4fmgQN jgc5ifaJtM8SB5tc9u9t61r1K+HhXEZDikpNVlRu4kZJWG4kdkWiCG3aMvxEIu9bnTx m+NiWzde9DMp7Eb5gaD98As1j6zgWVenscyDXGpHhnvWw4fMGPbwT6YttnUpu5sdPMP hWoAL05IyWLXbeglJk7Zszc3RMVwVX1GRHn29D6feLMnUYMIfTseKaz+spyN0+IXknU WtBBNVgq1Q== DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=7v7vs6w47njt4pimodk5mmttbegzsi6n; d=amazonses.com; t=1721515536; h=Subject:From:To:Date:Mime-Version:Content-Type:References:Message-Id:Feedback-ID; bh=yYQM4ZlR2h5xiG/S/D1WFz4lnQGIBp5tBUnY89XyaLU=; b=kuu4gRENp5oCr0EwJAeJq4c5bM5dETBDBrCR48++49rzvcYslJAocE92ml184zDq txi9+mSwNx1r0YMDnHUcYhHzO1ctusbAEyuGXi0vmIy+TmPap/OA4F2zAsaaY7HefbN wqvkRFDLJ5lgjUxnj3yHC6Wvvi1AnIij59OYmuMU= Subject: Bloated pg_catalog.pg_largeobjects From: postgresql@thewickedtribe.net To: =?UTF-8?Q?pgsql-general=40postgresql=2Eorg?= Date: Sat, 20 Jul 2024 22:45:36 +0000 Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=_fU3DaHAH6f1IHMyUdIrMY9RTBH4Ez1gBle6jPIs765U1HG1K" References: X-Priority: 3 (Normal) X-Mailer: Amazon WorkMail Thread-Index: AQHa2vZPQmCh66b1RASHretbYzZKCw== Thread-Topic: Bloated pg_catalog.pg_largeobjects X-Wm-Sent-Timestamp: 1721515535 Message-ID: <01010190d2526ef9-5d0a93fe-30ad-4d6b-9bc8-269c188bd42e-000000@us-west-2.amazonses.com> Feedback-ID: ::1.us-west-2.An468LAV0jCjQDrDLvlZjeAthld7qrhZr+vow8irkvU=:AmazonSES X-SES-Outgoing: 2024.07.20-54.240.27.28 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk This is a multi-part message in MIME format. Your mail reader does not understand MIME message format. --=_fU3DaHAH6f1IHMyUdIrMY9RTBH4Ez1gBle6jPIs765U1HG1K Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello All, I've got a cluster that's having issues with pg_catalog.pg_largeobject ge= tting massively bloated. Vacuum is running OK and there's 700GB of free s= pace in the table and only 100GB of data, but subsequent inserts seem to = be not using space from the FSM and instead always allocating new pages. = The table just keeps growing. Is this a known thing, maybe something special about LOs=3F Also, is the only way to recover space here a vacuum full on the table si= nce it's a catalog table=3F Thanks, --=C2=A0 Jon Erdman (aka StuckMojo on IRC) =C2=A0=C2=A0=C2=A0 PostgreSQL Zealot --=_fU3DaHAH6f1IHMyUdIrMY9RTBH4Ez1gBle6jPIs765U1HG1K Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable = Bloated pg_catalog.pg_largeobjects

Hello All,

I've got= a cluster that's having issues with pg_catalog.pg_largeobject getting ma= ssively bloated. Vacuum is running OK and there's 700GB of free space in = the table and only 100GB of data, but subsequent inserts seem to be not u= sing space from the FSM and instead always allocating new pages. The tabl= e just keeps growing.

Is this a known thing, maybe something speci= al about LOs=3F

Also, is the only way to recover space here a vacu= um full on the table since it's a catalog table=3F

Thanks,

-- 
Jon= Erdman (aka StuckMojo on IRC)
    PostgreSQL Zealot --=_fU3DaHAH6f1IHMyUdIrMY9RTBH4Ez1gBle6jPIs765U1HG1K--