Re: [HACKERS] ginInsertCleanup called from vacuum could still miss tuples to be deleted
Masahiko Sawada <sawada.mshk@gmail.com>
From: Masahiko Sawada <sawada.mshk@gmail.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2017-11-16T12:08:19Z
Lists: pgsql-hackers
Attachments
- fix_ginInsertCleanup_v2.patch (application/octet-stream) patch v2
On Thu, Nov 16, 2017 at 11:24 AM, Robert Haas <robertmhaas@gmail.com> wrote: > 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? > Agreed, that's better. Attached updated patch. Also I've added this to the next CF so as not to forget. Regards, -- Masahiko Sawada NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center
Commits
-
Fix broken cleanup interlock for GIN pending list.
- 19648ce55336 9.6.7 landed
- c8df4831ef21 10.2 landed
- 3b2787e1f8f1 11.0 landed
-
Prevent multiple cleanup process for pending list in GIN.
- e2c79e14d998 9.6.0 cited
-
Add pages deleted from pending list to FSM
- e95680832854 9.6.0 cited
-
Fix race condition in GIN posting tree page deletion.
- ac4ab97ec05e 9.4.0 cited