From: Tom Lane <tgl@sss.pgh.pa.us>
To: Mike Schanne <mschanne@kns.com>
cc: "'Jeff Janes'" <jeff.janes@gmail.com>,
        "'pgsql-performance@postgresql.org'"
 <pgsql-performance@postgresql.org>
Subject: Re: autovacuum locking question
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>
Comments: In-reply-to Mike Schanne <mschanne@kns.com>
	message dated "Fri, 06 Dec 2019 15:55:32 +0000"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <16364.1575652765.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Fri, 06 Dec 2019 12:19:25 -0500
Message-ID: <16365.1575652765@sss.pgh.pa.us>
Precedence: bulk

Mike Schanne <mschanne@kns.com> writes:
> The error is not actually showing up very often (I have 8 occurrences fr=
om 11/29 and none since then).  So maybe I should not be concerned about i=
t.  I suspect we have an I/O bottleneck from other logs (i.e. long checkpo=
int 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