On Fri, Apr 21, 2023 at 5:19 PM Aleksander Alekseev <aleksan...@timescale.com> wrote: > Naturally the database is consistent too. So it looks like the > recovery protocol worked as expected after all, at least in the > upcoming PG16 and this specific scenario. > > Did I miss anything? If not, perhaps we should just update the comments a bit?
I was confused about what was happening here but after trying to reproduce I think I figured it out. In my test, I saw the .1 file grow to a full 1GB and then the truncate happened afterward. Unsurprisingly, that works. I believe that what's happening here is that the DELETE statement triggers FPIs for all of the blocks it touches. Therefore, when the DELETE records are replayed, those blocks get written back to the relation, extending it. That gets it up to the required 1GB size after which the .2 file is visible to the smgr again, so the truncate works fine. I think that to reproduce the scenario, you want the truncate to happen in its own checkpoint cycle. I also found out from Andres that he's complained about pretty much the same problem just a couple of months ago: https://www.postgresql.org/message-id/20230223010147.32oir7sb66slq...@awork3.anarazel.de -- Robert Haas EDB: http://www.enterprisedb.com