Re: Why doesn't GiST VACUUM require a super-exclusive lock, like nbtree VACUUM?
x4mmm@yandex-team.ru
From: Andrey Borodin <x4mmm@yandex-team.ru>
To: Peter Geoghegan <pg@bowt.ie>
Cc: "pgsql-hackers@lists.postgresql.org" <pgsql-hackers@lists.postgresql.org>,
"hlinnaka@iki.fi" <hlinnaka@iki.fi>
Date: 2021-11-05T10:26:09Z
Lists: pgsql-hackers
> 4 нояб. 2021 г., в 20:58, Peter Geoghegan <pg@bowt.ie> написал(а): > That's a pretty unlikely scenario. And even > if it happened it would only happen once (until the next time we get > unlucky). What are the chances of somebody noticing a more or less > once-off, slightly wrong answer? I'd say next to impossible, yet not impossible. Or, perhaps, I do not see protection from this. Moreover there's a "microvacuum". It kills tuples with BUFFER_LOCK_SHARE. AFAIU it should take cleanup lock on buffer too? Best regards, Andrey Borodin.
Commits
-
Standardize cleanup lock terminology.
- bcf60585e6e0 15.0 landed
-
Reduce pinning and buffer content locking for btree scans.
- 2ed5b87f96d4 9.5.0 cited