With pending cleanup patch backend will try to get lock on metapage with ConditionalLockPage. Will it interrupt autovacum worker?There are only 3 fundamental options I see, the cleaner can wait, "help", or move on."Helping" is what it does now and is dangerous. Moving on gives the above-discussed unthrottling problem. Waiting has two problems. The act of waiting will cause autovacuums to be canceled, unless ugly hacks are deployed to prevent that. If we deploy those ugly hacks, then we have the problem that a user backend will end up waiting on an autovacuum to finish the cleaning, and the autovacuum is taking its sweet time due to autovacuum_vacuum_cost_delay. (The "helping" model avoids this problem because the user backend can just catch up with and pass the io-throttled autovac process)
For completeness sake, a fourth option would to move on, but only after inserting the tuple directly into the main index structure (rather then the pending list) like would be done with fastupdate off, once the pending list is already oversized. This is my favorite, but there is no chance of it going into 9.6, much less being backpatched.
Agree, will reimplement for 9.7
Alvaro's recommendation, to let the cleaner off the hook once it passes the page which was the tail page at the time it started, would prevent any process from getting pinned down indefinitely, but would not prevent the size of the list from increasing without bound. I think that would probably be good enough, because the current throttling behavior is purely accidentally and doesn't *guarantee* a limit on the size of the pending list.
Added, see attached patch (based on v3.1)
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http://www.sigaev.ru/
gin_alone_cleanup-4.patch
Description: binary/octet-stream
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
