Re: pg_amcheck contrib application

Поиск
Список
Период
Сортировка
От Mark Dilger
Тема Re: pg_amcheck contrib application
Дата
Msg-id 8CE17574-003D-4FFB-8C87-9BB119E8E813@enterprisedb.com
обсуждение исходный текст
Ответ на Re: pg_amcheck contrib application  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers

> On Mar 23, 2021, at 12:05 PM, Robert Haas <robertmhaas@gmail.com> wrote:
>
> 005 is doing "logical"
> damage rather than "physical" damage, and I don't see why autovacuum
> should misbehave in that kind of case. In fact, the fact that
> autovacuum can handle such cases is one of the selling points for the
> whole design of vacuum, as opposed to, for example, retail index
> lookups.

That is a good point.  Checking that autovacuum behaves sensibly despite sort order breakage sounds reasonable, but
test005 doesn't do that reliably, because it does nothing to make sure that autovacuum runs against the affected table
duringthe short window when the affected table exists.  All the same, I don't see that turning autovacuum off is
required. If autovacuum is broken in this regard, we may get occasional, hard to reproduce build farm failures, but
thatwould be more informative than no failures at all. 

—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company






В списке pgsql-hackers по дате отправления:

Предыдущее
От: Stephen Frost
Дата:
Сообщение: Re: Change default of checkpoint_completion_target
Следующее
От: Jan Wieck
Дата:
Сообщение: Re: pg_upgrade failing for 200+ million Large Objects