Re: Why doesn't GiST VACUUM require a super-exclusive lock, like nbtree VACUUM? - Mailing list pgsql-hackers

From Andrey Borodin
Subject Re: Why doesn't GiST VACUUM require a super-exclusive lock, like nbtree VACUUM?
Date
Msg-id CA989C25-C66B-4D5D-94D2-F4F095A46120@yandex-team.ru
Whole thread Raw
In response to Re: Why doesn't GiST VACUUM require a super-exclusive lock, like nbtree VACUUM?  (Peter Geoghegan <pg@bowt.ie>)
Responses Re: Why doesn't GiST VACUUM require a super-exclusive lock, like nbtree VACUUM?
List 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.


pgsql-hackers by date:

Previous
From: Andrey Borodin
Date:
Subject: Re: Supply restore_command to pg_rewind via CLI argument
Next
From: Hayk Manukyan
Date:
Subject: Re: Feature request for adoptive indexes