EvictUnpinnedBuffer and buffer free list - Mailing list pgsql-hackers

From Ashutosh Bapat
Subject EvictUnpinnedBuffer and buffer free list
Date
Msg-id CAExHW5tRzjmJ1At7BAb4VjiJMDmwiNTtx_DOhx96gYtSJvBS+g@mail.gmail.com
Whole thread Raw
Responses Re: EvictUnpinnedBuffer and buffer free list
List pgsql-hackers
Hi All,
EvictUnpinnedBuffer() calls InvalidateVictimBuffer() followed by
UnpinBuffer() before returning. None of those functions put the buffer
back into the free list. Its freeNext remains set to
FREENEXT_NOT_IN_LIST. I think then that buffer will never be used and
lost forever. I know that that function is only meant for development
or testing but even while testing something losing a buffer forever
seems like a problem.

The prologue of function InvalidateVictimBuffer() says "/* Helper
routine for GetVictimBuffer() ". I believe that it's expected that the
buffer will be allocated to some other page, and that's why it doesn't
return the buffer to the free list. But in the case of
EvictUnpinnedBuffer() we are not using that buffer for any page, so it
must be returned to the free list. InvalidateBuffer() does that but
its prologue mentions that it's supposed to be used when freeing
buffers for relations and databases.

I think there are two solutions
1. Use InvalidBuffer() instead of InvalidateVictimBuffer(). But I am
not sure whether that's safe or what other safety measures we have to
put in EvictUnpinnedBuffer()
2. Call StrategyFreeBuffer() after InvalidateVictimBuffer()

Thoughts?

-- 
Best Wishes,
Ashutosh Bapat



pgsql-hackers by date:

Previous
From: Peter Smith
Date:
Subject: Re: Introduce XID age and inactive timeout based replication slot invalidation
Next
From: Lukas Fittl
Date:
Subject: Re: [PATCH] Optionally record Plan IDs to track plan changes for a query