On Thu, Oct 05, 2023 at 11:28:02PM +0000, Imseih (AWS), Sami wrote:
> I spent sometime studying this and it appears to be a good approach.
>
> Passing the cutoff page as headPage (SLRU not needed code path ) instead of the tailPage to
> SimpleLruTruncate is already being done when the tailXid is not a valid XID.
> I added an additional condition to make sure that the tailPage proceeds the headPage
> as well.
I have been studying the whole area, and these threads from 2011 have
come to me, with two separate attempts:
https://www.postgresql.org/message-id/4DF105ED.1050800@enterprisedb.com
https://www.postgresql.org/message-id/4D8F54E6020000250003BD16%40gw.wicourts.gov
Back then, we were pretty much OK with the amount of space that could
be wasted even in this case. Actually, how much space are we talking
about here when a failed truncation happens? As this is basically
harmless, still leads to a confusing message, do we really need a
backpatch here?
Anyway, it looks like you're right, we don't really need the SLRU once
the tail is ahead of the tail because the SLRU has wrapped around due
to the effect of transactions aging out, so making the truncation a
bit smarter should be OK.
+ /*
+ * Check if the tailXid is valid and that the tailPage is not ahead of
+ * the headPage, otherwise the SLRU is no longer needed.
+ */
Hmm. This doesn't seem enough. Shouldn't we explain at least in
which scenarios the tail can get ahead of the head (aka at least
with long running transactions that make the SLRU wrap-around)?
Except if I am missing something, there is no explanation of that in
predicate.c.
--
Michael