Re: Add pg_buffercache_evict_all() and pg_buffercache_mark_dirty[_all]() functions - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Add pg_buffercache_evict_all() and pg_buffercache_mark_dirty[_all]() functions
Date
Msg-id lbnhztfm6dphofz3o3gxgtastqlnwztb6gz4cmvjqpcchmwapf@bar5wopwdbgz
Whole thread Raw
In response to Re: Add pg_buffercache_evict_all() and pg_buffercache_mark_dirty[_all]() functions  (Nazir Bilal Yavuz <byavuz81@gmail.com>)
Responses Re: Add pg_buffercache_evict_all() and pg_buffercache_mark_dirty[_all]() functions
List pgsql-hackers
Hi,

On 2025-04-08 03:15:57 +0300, Nazir Bilal Yavuz wrote:
> On Tue, 8 Apr 2025 at 02:29, Andres Freund <andres@anarazel.de> wrote:
> > On 2025-04-07 19:37:50 +0300, Nazir Bilal Yavuz wrote:
> > > > > > > +     relation_close(rel, AccessExclusiveLock);
> > > > > >
> > > > > > Hm. Why are we dropping the lock here early? It's probably ok, but it's not
> > > > > > clear to me why we should do so.
> > > > >
> > > > > We are dropping the lock after we processed the relation. I didn't
> > > > > understand what could be the problem here. Why do you think it is
> > > > > early?
> > > >
> > > > Most commonly we close relations without releasing the lock, instead relying
> > > > on the lock being released at the end of the transaction.
> > >
> > > I see. I was looking at pg_prewarm as an example and copied it from there.
> >
> > I don't think we're particularly consistent about it. And I think there's some
> > differing views about what precisely the right behaviour is...
> >
> >
> > I've tried to polish the patch.  Changes I made:
> >
> > - The number of processed buffers for EvictAllUnpinnedBuffers() was alwasy
> >   NBuffers, that didn't seem right. But that's obsoleted by the next point:
> >
> > - I think it'd be more useful to return the number of skipped buffers,
> >   i.e. buffers that could not be evicted, than the number of processed
> >   buffers.
> 
> I agree. The number of buffers that we tried to evict but couldn't
> evict will give more information rather than NBuffers.

Cool.

> >
> >   I'm not_evicted or such would also work.
> 
> Did you mean that 'not_evicted' can be used instead of
> 'skipped_buffers' as a column name? If that is the case, both are okay
> to me.

Correct, sorry for that garbled sentence.


> > - I don't love the buffers_ prefix for the column names / C function
> >   arguments. Seems long.  It seems particularly weird because
> >   pg_buffercache_evict() doesn't have a buffer_ prefix.
> >
> >   I left it as-is, but I think something perhaps ought to change before
> >   commit.
> 
> Both are okay to me, I still couldn't decide which I like more.

I went back and forth at least three times.  In the end I added the buffer_
(singular) prefix for pg_buffercache_evict().


> > - The documentation format of the functions isn't quite what we usually do (a
> >   table documenting the columns returned by a function with multiple columns),
> >   but otoh, these are really developer oriented functions, so spending 30
> >   lines of a <table> on each of these functions feels a bit silly.
> >
> >   I'd be ok with it as-is.
> >
> > - The docs for pg_buffercache_evict() don't quite sound right to me, there's
> >   some oddity in the phrasing.  Nothing too bad, but perhaps worht a small bit
> >   of additional polish.
> 
> I tried to update it without changing the old doc, perhaps that was
> the wrong move.

I think it's ok for now.  It might be worth doing a larger redesign of the
pgbuffercache docs at some point...


Pushed.


Thanks for your patches and thanks for all the reviewers getting this ready!


Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Richard Guo
Date:
Subject: Re: An incorrect check in get_memoize_path
Next
From: Bertrand Drouvot
Date:
Subject: Re: Fix 035_standby_logical_decoding.pl race conditions