Re: [HACKERS] ginInsertCleanup called from vacuum could still misstuples to be deleted

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: [HACKERS] ginInsertCleanup called from vacuum could still misstuples to be deleted
Дата
Msg-id CA+Tgmob_7nw_DzS3M-v0VStVdyJGE7bF13AxyEf4NEhEWDmnaA@mail.gmail.com
обсуждение исходный текст
Ответ на [HACKERS] ginInsertCleanup called from vacuum could still miss tuples to be deleted  (Masahiko Sawada <sawada.mshk@gmail.com>)
Ответы Re: [HACKERS] ginInsertCleanup called from vacuum could still misstuples to be deleted  (Masahiko Sawada <sawada.mshk@gmail.com>)
Список pgsql-hackers
On Mon, Nov 13, 2017 at 3:25 AM, Masahiko Sawada <sawada.mshk@gmail.com> wrote:
> In ginInsertCleanup(), we lock the GIN meta page by LockPage and could
> wait for the concurrent cleaning up process if stats == NULL. And the
> source code comment says that this happen is when ginINsertCleanup is
> called by [auto]vacuum/analyze or gin_clean_pending_list(). I agree
> with this behavior. However, looking at the callers the stats is NULL
> only either if pending list exceeds to threshold during insertions or
> if only analyzing is performed by an autovacum worker or ANALYZE
> command. So I think we should inVacuum = (stats != NULL) instead.

Argh.  Yeah, that looks wrong.

Instead of relying on this indirect method, how about passing an
explicit inVacuum argument to that function?  And while we're at it,
how about renaming inVacuum to forceCleanup?

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


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

Предыдущее
От: Amit Langote
Дата:
Сообщение: Re: [HACKERS] moving some partitioning code to executor
Следующее
От: Amit Kapila
Дата:
Сообщение: Re: [HACKERS] [POC] Faster processing at Gather node