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>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Cc: "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-04 15:52:22
Message-ID: 117861636040149@mail.yandex-team.ru
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

<div> </div><div> </div><div>04.11.2021, 04:33, "Peter Geoghegan" &lt;pg(at)bowt(dot)ie&gt;:</div><blockquote><p>But what about index-only scans, which GiST also supports? I think<br />that the rules are different there, even though index-only scans use<br />an MVCC snapshot.</p></blockquote><p>Let's enumerate steps how things can go wrong.</p><p>Backend1: Index-Only scan returns tid and xs_hitup with index_tuple1 on index_page1 pointing to heap_tuple1 on page1</p><p>Backend2: Remove index_tuple1 and heap_tuple1</p><div><div>Backend3: Mark page1 all-visible</div><div>Backend1: Thinks that page1 is all-visible and shows index_tuple1 as visible</div><div> </div><div>To avoid this Backend1 must hold pin on index_page1 until it's done with checking visibility, and Backend2 must do LockBufferForCleanup(index_page1). Do I get things right?</div><div> </div><div>Best regards, Andrey Borodin.</div></div><div> </div>

Attachment Content-Type Size
unknown_filename text/html 923 bytes

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message vignesh C 2021-11-04 15:57:43 Re: Skipping logical replication transactions on subscriber side
Previous Message Robert Haas 2021-11-04 15:04:58 Re: should we enable log_checkpoints out of the box?