On Wed, Jul 19, 2023 at 12:45 PM Andres Freund <and...@anarazel.de> wrote: > I don't think "invalidating" is the right terminology. Note that we already > have InvalidateBuffer() - but it's something we can't allow users to do, as it > throws away dirty buffer contents (it's used for things like dropping a > table). > > How about using "discarding" for this functionality?
+1 > Using the buffer ID as the identifier doesn't seem great, because what that > buffer is used for, could have changed since the buffer ID has been acquired > (via the pg_buffercache view presumably)? > > My suspicion is that the usual usecase for this would be to drop all buffers > that can be dropped? Well the idea was to be able to drop less than everything. Instead of having to bike-shed what the user interface should look like to specify what subset of everything you want to drop, you can just write SQL queries (mostly likely involving the pg_buffercache view, indeed). It's true that buffer IDs can change underneath your feet between SELECT and discard, but the whole concept is inherently racy like that. Suppose we instead had pg_unwarm('my_table') or whatever instead. Immediately after it runs and before it even returns, some blocks of my_table can finish up coming back into the pool. It's also interesting to be able to kick individual pages out when testing code that caches buffers IDs for ReadRecentBuffer(), and other buffer-pool work. Hence desire to not try to be clever at all here, and just come up with the absolute bare minimum thing that can kick buffers out by ID and leave the rest up to hackers/experts who are willing and able to write queries to supply them. You can still drop everything that can be dropped -- generate_series. Or whatever you want.