On Wed, Jan 4, 2023 at 7:03 AM Robert Haas <robertmh...@gmail.com> wrote: > But that having been said, I'm kind of astonished that you didn't know > about this already. The freezing behavior is in general extremely hard > to get right, and I guess I feel if you don't understand how the > underlying functions work, including things like performance > considerations
I was the one that reported the issue with CLOG lookups in the first place. > and which functions return fully reliable results, I do > not think you should be committing your own patches in this area. My mistake here had nothing to do with my own goals. I was trying to be diligent by hardening an existing check in passing, and it backfired. > There is probably a lot of potential benefit in improving the way this > stuff works, but there is also a heck of a lot of danger of creating > subtle data corrupting bugs that could easily take years to find. It's currently possible for VACUUM to set the all-frozen bit while unsetting the all-visible bit, due to a race condition [1]. This is your long standing bug. So apparently nobody is qualified to commit patches in this area. About a year ago, there was a massive argument over some earlier work in the same general area, by me. Being the subject of a pile-on on this mailing list is something that I find deeply upsetting and demoralizing. I just cannot take much more of it. At the same time, I've made quite an investment in the pending patches, and think that it's something that I have to see through. If I am allowed to finish what I've started, then I will stop all new work on VACUUM. I'll go back to working on B-Tree indexing. Nobody is asking me to focus on VACUUM, and there are plenty of other things that I could be doing that don't seem to lead to these situations. [1] https://postgr.es/m/cah2-wznungszf8v6osgjac5aysb3cz6hw6mlm30x0d65cms...@mail.gmail.com -- Peter Geoghegan