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

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

  1. Fix broken cleanup interlock for GIN pending list.

  2. Prevent multiple cleanup process for pending list in GIN.

  3. Add pages deleted from pending list to FSM

  4. Fix race condition in GIN posting tree page deletion.