From: Tom Lane <tgl@sss.pgh.pa.us>
To: Mike Schanne <mschanne@kns.com>
Cc: 'Jeff Janes' <jeff.janes@gmail.com>
Cc: 'pgsql-performance@postgresql.org' <pgsql-performance@postgresql.org>
Subject: Re: autovacuum locking question
Date: Fri, 06 Dec 2019 12:19:25 -0500
Message-ID: <16365.1575652765@sss.pgh.pa.us> (raw)
In-Reply-To: <ad5b3b6459354e3ea65c33cc9fca14c0@USEPRDEX1.corp.kns.com>
References: <0871fcf35ceb4caa8a2204ca9c38e330@USEPRDEX1.corp.kns.com>
<CAMkU=1wmmOvKGC+_QqHBE=nM=nqPBq=DJrX8Sk3CeQ+krAcEkA@mail.gmail.com>
<ad5b3b6459354e3ea65c33cc9fca14c0@USEPRDEX1.corp.kns.com>
Mike Schanne <mschanne@kns.com> writes:
> The error is not actually showing up very often (I have 8 occurrences from 11/29 and none since then). So maybe I should not be concerned about it. I suspect we have an I/O bottleneck from other logs (i.e. long checkpoint sync times), so this error may be a symptom rather than the cause.
Well, it's also an inherently non-repeating problem: once some iteration
of autovacuum has managed to truncate away the large amount of trailing
dead space that the file presumably had, later runs won't need to do
that.
Of course, if you have a usage pattern that repeatedly bloats the table
with lots of stuff-to-be-vacuumed, the issue could recur that way.
regards, tom lane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: tgl@sss.pgh.pa.us, mschanne@kns.com, jeff.janes@gmail.com
Subject: Re: autovacuum locking question
In-Reply-To: <16365.1575652765@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox