Re: Temp table handling after anti-wraparound shutdown (Was: BUG#15840)
От | Michael Paquier |
---|---|
Тема | Re: Temp table handling after anti-wraparound shutdown (Was: BUG#15840) |
Дата | |
Msg-id | 20190607235937.GA1590@paquier.xyz обсуждение исходный текст |
Ответ на | Temp table handling after anti-wraparound shutdown (Was: BUG #15840) (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: Temp table handling after anti-wraparound shutdown (Was: BUG#15840)
|
Список | pgsql-hackers |
On Fri, Jun 07, 2019 at 03:58:43PM -0700, Andres Freund wrote: > Do we need to move the orphan temp cleanup code into database vacuums or > such? When entering into the vacuum() code path for an autovacuum, only one relation at a time is processed, and we have prior that extra processing related to toast relations when selecting the relations to work on, or potentially delete orphaned temp tables. For a manual vacuum, we finish by deciding which relation to process in get_all_vacuum_rels(), so the localized processing is a bit different than what's done in do_autovacuum() when scanning pg_class for relations. Technically, I think that it would work to give up on the gathering of the orphaned OIDs in a gathering and let them be gathered in the list of items to vacuum, and then put the deletion logic down to vacuum_rel(). However, there is a take: for autovacuum we gather the orphaned entries and the other relations to process, then drop all the orphaned OIDs, and finally vacuum/analyze the entries collected. So if you put the deletion logic down into vacuum_rel() then we won't be able to drop orphaned tables before working on a database, which would be bad if we know about an orphaned set, but autovacuum works for a long time on other legit entries first. -- Michael
Вложения
В списке pgsql-hackers по дате отправления: