Committed. I noticed two things that I felt I should note here:
* For the vacuum path, we call pgstat_progress_end_command() prior to accessing the value. This works because pgstat_progress_end_command() doesn't clear the st_progress_param array (that is done in pgstat_progress_start_command()). AFAICT it's worked this way since this stuff was introduced ~9 years ago, and I have no reason to believe it will change anytime soon. * We are bypassing the changecount mechanism when accessing the value. I believe this is okay because the calling process is the only one that updates these values. Even in the parallel worker case, the worker sends a message to the leader to increment the value. Perhaps this could break in the future if we switched to using atomics or something, but that approach was already considered and abandoned once before [0], and the worst case scenario would likely be compiling errors or bogus delay values. So, I chose to just add comments about this stuff for now. If someone feels strongly that we should do pro forma changecount checks before pgstat_progress_end_command(), I'm happy to draft the patch. [0] https://postgr.es/m/72CD33F6-C2B5-45E4-A78F-85EC923DCF0F%40amazon.com -- nathan
