From: | Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [HACKERS] ginInsertCleanup called from vacuum could still miss tuples to be deleted |
Date: | 2017-11-16 12:08:19 |
Message-ID: | CAD21AoAV7-_16esnSMQO6gLg=OFJV0+WTSxJPSu3k36Q9bjocg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Nov 16, 2017 at 11:24 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Mon, Nov 13, 2017 at 3:25 AM, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)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
Attachment | Content-Type | Size |
---|---|---|
fix_ginInsertCleanup_v2.patch | application/octet-stream | 3.3 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Masahiko Sawada | 2017-11-16 12:15:01 | Re: [HACKERS] Remove duplicate setting in test/recovery/Makefile |
Previous Message | a.akenteva | 2017-11-16 12:05:59 | Re: [HACKERS] A weird bit in pg_upgrade/exec.c |