Re: Is there a way (except from server logs) to know the kind of on-going/last checkpoint?
От | Julien Rouhaud |
---|---|
Тема | Re: Is there a way (except from server logs) to know the kind of on-going/last checkpoint? |
Дата | |
Msg-id | 20220128161019.mhhgzmw4evy5m63l@jrouhaud обсуждение исходный текст |
Ответ на | Re: Is there a way (except from server logs) to know the kind of on-going/last checkpoint? (Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>) |
Ответы |
Re: Is there a way (except from server logs) to know the kind of on-going/last checkpoint?
|
Список | pgsql-hackers |
Hi, On Fri, Jan 28, 2022 at 08:21:52PM +0530, Bharath Rupireddy wrote: > > I don't think we need to change pg_upgrade's ControlData controldata; > structure as the information may not be needed there and the while > loop there specifically parses/searches for the required > pg_controldata output texts. Am I missing something here? Right, I was remembering that there was a check that all expected fields were found but after double checking I was clearly wrong, sorry about that. > > > Also, you still didn't fix the possible flag upgrade issue. Unless I'm missing something that's an issue that you still haven't addressed or explained why it's not a problem? > > > Why are you defining CHECKPOINT_KIND_TEXT_LENGTH twice? You > > should just define it in some sensible header used by both files, or better > > have a new function to take care of that rather than having the code > > duplicated. > > Yeah, added the macro in pg_control.h. I also wanted to have a common > function to get checkpoint kind text and place it in > controldata_utils.c, but it doesn't have xlog.h included, so no > checkpoint flags there, hence I refrained from the common function > idea. That's a bit annoying, I'm not sure what's best to do here.
В списке pgsql-hackers по дате отправления: