On Fri, Nov 4, 2022 at 4:27 AM Drouvot, Bertrand <bertranddrouvot...@gmail.com> wrote: > Please find attached a rebase in v7.
I don't think it's a good thing that this patch is using the progress-reporting machinery. The point of that machinery is that we want any backend to be able to report progress for any command it happens to be running, and we don't know which command that will be at any given point in time, or how many backends will be running any given command at once. So we need some generic set of counters that can be repurposed for whatever any particular backend happens to be doing right at the moment. But none of that applies to the checkpointer. Any information about the checkpointer that we want to expose can just be advertised in a dedicated chunk of shared memory, perhaps even by simply adding it to CheckpointerShmemStruct. Then you can give the fields whatever names, types, and sizes you like, and you don't have to do all of this stuff with mapping down to integers and back. The only real disadvantage that I can see is then you have to think a bit harder about what the concurrency model is here, and maybe you end up reimplementing something similar to what the progress-reporting stuff does for you, and *maybe* that is a sufficient reason to do it this way. But I'm doubtful. This feels like a square-peg-round-hole situation. -- Robert Haas EDB: http://www.enterprisedb.com
