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 1tZKqx-0074jr-Ba for pgsql-admin@arkaria.postgresql.org; Sun, 19 Jan 2025 02:15:55 +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 1tZKqu-004BCp-6n for pgsql-admin@arkaria.postgresql.org; Sun, 19 Jan 2025 02:15:52 +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 1tZKqt-004BCg-QP for pgsql-admin@lists.postgresql.org; Sun, 19 Jan 2025 02:15:52 +0000 Received: from mail-vs1-xe2f.google.com ([2607:f8b0:4864:20::e2f]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1tZKqs-000JeE-10 for pgsql-admin@lists.postgresql.org; Sun, 19 Jan 2025 02:15:51 +0000 Received: by mail-vs1-xe2f.google.com with SMTP id ada2fe7eead31-4b24bc0cc65so2157037137.2 for ; Sat, 18 Jan 2025 18:15:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1737252950; x=1737857750; darn=lists.postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=HozK7untEqTCfyIWWhaTNvLvczA3IVHUyqD9zaXq4fc=; b=Yg0ImkzPSVnmYt/gyCk/Akvv9P1CjVGsmBsdn5I2zT5aQUMhgOew9fPG6CncVIv9Sh TWZSEi0QPYjRfskgJj6jAg/T/6jqpWSUFLHvGDvAo6jsS3CwlkJxnNtbkwkRSflDr+6H CiT5Qs/gNvpUIJj+0dzhe4o66blE99t+8oSWNPNm9p2IAy8/ip42HbYOS8IQ/6HWt4G7 b+HfrICH9Ha8nkxgiJnjnJOJcd9Pfc7X22lu1GtmAJ2fZMI/4Br2/i8GSH8V+R97qK4q jPhgHMghT3GqDXgBrczz8DuqTZzr9JkBHqcgjt5PszUp1AlAO/rmz7UZN/4HzBtVgpRr pAmA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1737252950; x=1737857750; h=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=HozK7untEqTCfyIWWhaTNvLvczA3IVHUyqD9zaXq4fc=; b=PatvmWrMiQMhiGInq51Q305b/eEaYqLYnxd1fIQy5JQrzoX2qvf3kIQBsu3h0ctvSV OG6J3RlCuXcraHoiTMyVU8v+S1tu6gQdIiMO+QYXkkicubsN67KFoxF6NQhnW6p26xWu Am4PjYtDUZbt8ma9oY/MTtDGF8rw8rMBXHsj1sOPbeipqW1veTnRL839BxKwdgdtagHo NPeS5SGyf+Udqr2jf/qSV/ZoFgOawov1Y15q7r309NaiHONfrZj88xCrZLndhZh7jwkP bqPJ5CLEcvG/ptAXS8738o9YT17Uo+rg8on4I4xc3xmEqzeNWwdIt2kfaOyxnUvm2z7u 6Cig== X-Gm-Message-State: AOJu0YytBBMvbabDxyzmD18yn/5dVpTOR55Qo3GaXsnineoS5dGZZhs8 RtEPRDbMcO8Uf89+ksyWNzGtYGsYhlTIJMD2dPDLEUinqVHxICmujzjK7va6KZpBIRTegcsPAEZ fITYcEDmtTSPdASfU9mDbK9jA+A== X-Gm-Gg: ASbGncslVNGN71KAaJudmQm1wSB/trhY4HSCYlND3hAqDOnbewpCzIAQsS1w5SWVtuq eqvOHpusLRE37o1JBZU4h+T2fniCHzTqTdzcr5nbiwH6utCknFKvTuOgkGs/QFgR1S9s4pG+lza FBdFzghOk= X-Google-Smtp-Source: AGHT+IFbsqUVeePFO/wnpbUFkrkBFz+6mP6EMZNFTYC9qkew93HNHY/oguyjEvI8ZUM7DZWyflcacnLYoGyzu4810CM= X-Received: by 2002:a05:6102:dce:b0:4b2:5c4b:55e9 with SMTP id ada2fe7eead31-4b690b7bfa1mr7901084137.3.1737252949809; Sat, 18 Jan 2025 18:15:49 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Jeff Janes Date: Sat, 18 Jan 2025 21:15:37 -0500 X-Gm-Features: AbW1kvbFXPkleWywCISYPVyFXcheEOVk9GhBh-Ws59BJMH9CnZqcpn5JlbX4qeM Message-ID: Subject: Re: vacuuming taking long time for pg_attribute To: Siraj G Cc: Pgsql-admin Content-Type: multipart/alternative; boundary="000000000000f5614e062c05b80f" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000f5614e062c05b80f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Jan 17, 2025 at 1:15=E2=80=AFAM Siraj G wrote= : > Hello Experts! > > The PgSQL version is 16 and it runs in Cloud SQL managed by GCP. > > Problem was that we were unable to conveniently get the object details in > the schema browser (within the Cloud SQL Studio) as it was getting timeou= t > again and again. Several application jobs start to fail. Eventually we > found that pg_catalog.pg_attribute was having tons of dead tuples. While > vacuum on this took several hours, the problem got resolved eventually. > Command ran: vacuum pg_attribute; > > I would like to understand how this issue can be prevented. We do have > autovacuum ON and I could see the last vacuum on this table was just abou= t > 30hrs back. > It might be hard to figure it out now that the evidence has likely been destroyed. When looking at when the last autovac finished, did you also happen to capture the other column values in pg_stat_sys_tables for that relname? Look in the db server log file to see if there were failed or canceled autovacuum attempts on that table. I would probably set log_autovacuum_min_duration to a smallish value so that if it happens again you have some evidence to look at. Cheers, Jeff > --000000000000f5614e062c05b80f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Jan 17, 2025 at 1:15=E2=80=AFAM S= iraj G <tosiraj.g@gmail.com&g= t; wrote:
He= llo Experts!

The PgSQL version is 16 and it runs in Clou= d SQL managed by GCP.

Problem was that we were una= ble to conveniently=C2=A0get the object details in the schema browser (with= in the Cloud SQL Studio) as it was getting timeout again and again. Several= application jobs start to fail. Eventually we found that pg_catalog.pg_att= ribute was having tons of dead tuples. While vacuum on this took several ho= urs, the problem got resolved eventually.
Command ran: vacuum pg_= attribute;

I would like to understand how this iss= ue can be prevented. We do have autovacuum ON and I could see the last vacu= um on this table was just about 30hrs back.
<= div>
It might be hard to figure it out now that=C2=A0the evid= ence has likely been destroyed.=C2=A0 When looking at when the last autovac= finished, did you also happen to capture=C2=A0the other column=C2=A0values= in pg_stat_sys_tables for that relname?

Look in t= he db server log file to see if there were failed or canceled autovacuum at= tempts on that table.

I would probably set log_aut= ovacuum_min_duration to a smallish value so that if it happens again you ha= ve some evidence to look at.

Cheers,
Jeff
--000000000000f5614e062c05b80f--