From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Mike Schanne <mschanne(at)kns(dot)com> |
Cc: | "'Jeff Janes'" <jeff(dot)janes(at)gmail(dot)com>, "'pgsql-performance(at)postgresql(dot)org'" <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: autovacuum locking question |
Date: | 2019-12-06 17:19:25 |
Message-ID: | 16365.1575652765@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Mike Schanne <mschanne(at)kns(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Jeff Janes | 2019-12-06 17:47:56 | Re: autovacuum locking question |
Previous Message | Mike Schanne | 2019-12-06 17:18:20 | unexpected result for wastedbytes query after vacuum full |