Horton

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

Michail Nikolaev <michail.nikolaev@gmail.com>

View thread View on postgr.es
From: Michail Nikolaev <michail.nikolaev@gmail.com>
To: Matthias van de Meent <boekewurm+postgres@gmail.com>
Cc: Peter Geoghegan <pg@bowt.ie>, pgsql-hackers@lists.postgresql.org, hlinnaka@iki.fi, Tom Lane <tgl@sss.pgh.pa.us>, Andres Freund <andres@anarazel.de>, Tomas Vondra <tomas@vondra.me>
Date: 2025-01-09T21:00:03Z
Lists: pgsql-hackers 
Hello.

One thing I think we could add to the patches is to adapt the 10-years-old
comment below with notice about IOS:

/*
* We save the LSN of the page as we read it, so that we know whether it
* safe to apply LP_DEAD hints to the page later. This allows us to drop
* the pin for MVCC scans, which allows vacuum to avoid blocking.
*/
so->curPageLSN = BufferGetLSNAtomic(buffer);


Also, I think it is a good idea to add "Assert(!scan->xs_want_itup);"
to gistkillitems.

Best regards,
Mikhail.

Commits

  1. Standardize cleanup lock terminology.

  2. Reduce pinning and buffer content locking for btree scans.