GIN vacuum bug - Mailing list pgsql-hackers

From Teodor Sigaev
Subject GIN vacuum bug
Date
Msg-id 56041B26.2040902@sigaev.ru
Whole thread Raw
Responses Re: GIN vacuum bug  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Hi!

After reading thread

http://www.postgresql.org/message-id/flat/CAMkU=1xALfLhUUohFP5v33RzedLVb5aknNUjcEuM9KNBKrB6-Q@mail.gmail.com#CAMkU=1xALfLhUUohFP5v33RzedLVb5aknNUjcEuM9KNBKrB6-Q@mail.gmail.com

I agree, that it's a bug, although, seems, with low probability. I'd like to
suggest patch with introduces:
1 cleanup process could be only one at the same time
2 if cleanup called from regular insert sees waiting concurrent cleanup then
   it will stop process in hope that another cleanup is vacuum called.

Insert-called cleanup process locks metapage with
ConditionalLockPage(ExclusiveLock) and if it fails then just goes away, because
other cleanup is already in progress.  Also, insert-called cleanup process will
sometimes do lock/conditional lock metapage. Vacuum-called cleanup process locks
with a help of unconditional LockPage() and will not relock metapage during
process, that gives a warranty to be a single cleanup process. Relock of
insert-called cleanup process allows to leave a rest of work to vacuum if it
runs right now. This reduces latency for insert and allows to vacuum to be sure
that pending list is clear.

Also, patch differentiates which limit of memory to use: autovacuum_work_mem,
maintenance_work_mem or work_mem depending on call path.
--
Teodor Sigaev                                   E-mail: teodor@sigaev.ru
                                                    WWW: http://www.sigaev.ru/

Attachment

pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: clearing opfuncid vs. parallel query
Next
From: Tom Lane
Date:
Subject: Re: clearing opfuncid vs. parallel query