Hi, Robert! > Lest we miss the forest for the trees, there is an aspect of this > patch that I find to be an extremely good idea and think we should try > to get committed even if the rest of the patch set ends up in the > rubbish bin. Specifically, there are a couple of patches in here that > have to do with making SLRUs indexed by 64-bit integers rather than by > 32-bit integers. We've had repeated bugs in the area of handling SLRU > wraparound in the past, some of which have caused data loss. Just by > chance, I ran across a situation just yesterday where an SLRU wrapped > around on disk for reasons that I don't really understand yet and > chaos ensued. Switching to an indexing system for SLRUs that does not > ever wrap around would probably enable us to get rid of a whole bunch > of crufty code, and would also likely improve the general reliability > of the system in situations where wraparound is threatened. It seems > like a really, really good idea.
I totally support the idea that the part related to SLRU is worth committing whether it is being the first step to 64xid or separately. This subset is discussed in a separate thread [1]. It seems that we need more time to reach a consensus on the implementation of a whole big thing. Just this discussion is a complicated thing and reveals many different aspects concurrently in one thread. So I'd vote for an evolutionary approach and give my +1 for undertaking efforts to first committing [1] to 16. [1]: https://www.postgresql.org/message-id/CAFiTN-uudj2PY8GsUzFtLYFpBoq_rKegW3On_8ZHdxB1mVv3-A%40mail.gmail.com Kind regards, Pavel Borisov, Supabase.