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

From: Andrey Borodin <x4mmm(at)yandex-team(dot)ru>
To: Peter Geoghegan <pg(at)bowt(dot)ie>
Cc: "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>, "hlinnaka(at)iki(dot)fi" <hlinnaka(at)iki(dot)fi>
Subject: Re: Why doesn't GiST VACUUM require a super-exclusive lock, like nbtree VACUUM?
Date: 2021-11-05 10:26:09
Message-ID: CA989C25-C66B-4D5D-94D2-F4F095A46120@yandex-team.ru
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> 4 нояб. 2021 г., в 20:58, Peter Geoghegan <pg(at)bowt(dot)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.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Hayk Manukyan 2021-11-05 11:17:49 Re: Feature request for adoptive indexes
Previous Message Andrey Borodin 2021-11-05 10:10:29 Re: Supply restore_command to pg_rewind via CLI argument