Re: BUG #19014: Automatic aggressive VACUUM on template0 and template1 pg_shdepend runs every minute

From: 양주희 <1986comatose(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: depesz(at)depesz(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #19014: Automatic aggressive VACUUM on template0 and template1 pg_shdepend runs every minute
Date: 2025-08-11 09:09:09
Message-ID: CA+2eXpaYSVx9UGu6e-Yp53bN8hr-brTLmMYCrx5FO0avbLk_rw@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Hello, Thank you for your help. I ran the query you suggested: select now()
- xact_start from pg_stat_activity order by xact_start asc nulls last limit
1 The result was 00:00:00.96726, which suggests there are no long-running
transactions. Regarding Tom Lane's suggestion, our application does
frequently create temporary tables. This might be a factor contributing to
the constant vacuuming of pg_shdepend. I am ready to provide more
information if you need it to help reproduce the issue. Thank you

2025년 8월 8일 (금) 오전 6:33, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>님이 작성:

> hubert depesz lubaczewski <depesz(at)depesz(dot)com> writes:
> > On Thu, Aug 07, 2025 at 07:47:58AM +0000, PG Bug reporting form wrote:
> >> We only actively use the ecount database, yet our logs show that an
> >> automatic “aggressive” VACUUM is repeatedly running on
> >> template0.pg_catalog.pg_shdepend and template1.pg_catalog.pg_shdepend at
> >> roughly one-minute intervals. Since the template databases aren’t used
> for
> >> normal operations, these vacuums seem unnecessary and are consuming
> system
> >> resources. We believe this behavior is a bug.
>
> > I bet you have some long transaction somewhere, and this table is shared
> > (same table visible in all databases).
>
> Another theory, again remembering this is a shared catalog, is that
> there is enough update traffic on pg_shdepend to justify constant
> vacuuming. That could be plausible if there's a lot of object
> creation and deletion going on (even just temporary tables, I think).
>
> Anyway, I don't see any such behavior here after setting
> log_autovacuum_min_duration = 0. We're going to need more
> information to reproduce the problem.
>
> regards, tom lane
>

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Amit Kapila 2025-08-11 10:55:20 Re: Lock timeouts and unusual spikes in replication lag with logical parallel transaction streaming
Previous Message Zane Duffield 2025-08-11 06:20:56 Lock timeouts and unusual spikes in replication lag with logical parallel transaction streaming