Re: BUG #14941: Vacuum crashes
От | Bossart, Nathan |
---|---|
Тема | Re: BUG #14941: Vacuum crashes |
Дата | |
Msg-id | 1E4815BF-18D2-4184-989A-975728F59B88@amazon.com обсуждение исходный текст |
Ответы |
Re: BUG #14941: Vacuum crashes
Re: BUG #14941: Vacuum crashes |
Список | pgsql-hackers |
On 12/1/17, 11:16 AM, "Tomas Vondra" <tomas.vondra@2ndquadrant.com> wrote: >> The behavior I would like to see is that the void ignores this table and >> moves to another instead of being blocked. >> > > I believe autovacuum should not block waiting for a heavy-weight lock on > a table since this commit that went into 9.1: > > https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=32896c40ca766146312b28a5a0eb3f66ca0300ed > > So I'm wondering what problem you're running into. It sounds like Lyes is doing a periodic database-wide VACUUM that is getting blocked on certain relations that are already locked (perhaps because autovacuum is already working on it). IIUC, the ask is to provide a way to skip vacuuming relations that cannot be immediately locked. There is already an internal flag called VACOPT_NOWAIT that gives autovacuum this ability in certain cases (introduced in the aforementioned commit), and I recently brought up this potential use-case as justification for a patch [0]. I'd be happy to submit a patch for providing VACOPT_NOWAIT to users if others think it's something we should do. As a side note, this seems more like a feature request than a bug report, so I'm adding pgsql-hackers@ here, too. Nathan [0] https://www.postgresql.org/message-id/875815E8-7A99-4488-AA07-F254C404E2CF%40amazon.com
В списке pgsql-hackers по дате отправления: