Re: BUG #19014: Automatic aggressive VACUUM on template0 and template1 pg_shdepend runs every minute
| От | 양주희 |
|---|---|
| Тема | Re: BUG #19014: Automatic aggressive VACUUM on template0 and template1 pg_shdepend runs every minute |
| Дата | |
| Msg-id | CA+2eXpaYSVx9UGu6e-Yp53bN8hr-brTLmMYCrx5FO0avbLk_rw@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: BUG #19014: Automatic aggressive VACUUM on template0 and template1 pg_shdepend runs every minute (Tom Lane <tgl@sss.pgh.pa.us>) |
| Список | 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@sss.pgh.pa.us>님이 작성:
hubert depesz lubaczewski <depesz@depesz.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
В списке pgsql-bugs по дате отправления: