Re: Is there a way (except from server logs) to know the kind of on-going/last checkpoint?
От | Kyotaro Horiguchi |
---|---|
Тема | Re: Is there a way (except from server logs) to know the kind of on-going/last checkpoint? |
Дата | |
Msg-id | 20220131.111045.233166739136974829.horikyota.ntt@gmail.com обсуждение исходный текст |
Ответ на | Re: Is there a way (except from server logs) to know the kind of on-going/last checkpoint? (Julien Rouhaud <rjuju123@gmail.com>) |
Список | pgsql-hackers |
At Sat, 29 Jan 2022 00:10:19 +0800, Julien Rouhaud <rjuju123@gmail.com> wrote in > On Fri, Jan 28, 2022 at 08:21:52PM +0530, Bharath Rupireddy wrote: > > > 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? As Bharath said, pg_upgreade reads a part of old cluster's controldata that is needed to check compatibility so I agree that we don't have flag upgrade issue I mentioned. > > > 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. I misunderstood that the size is restricted to 8k but it is really 512 bytes as Andres pointed. So we don't add it at least as a text. This means pg_controldata need to translate the flags into human-readable text but, to be clear, I still don't think its usefull in the control data. regards. -- Kyotaro Horiguchi NTT Open Source Software Center
В списке pgsql-hackers по дате отправления: