Re: Add checkpoint and redo LSN to LogCheckpointEnd log message

Поиск
Список
Период
Сортировка
От Kyotaro Horiguchi
Тема Re: Add checkpoint and redo LSN to LogCheckpointEnd log message
Дата
Msg-id 20220104.104938.1202548681429146328.horikyota.ntt@gmail.com
обсуждение исходный текст
Ответ на Re: Add checkpoint and redo LSN to LogCheckpointEnd log message  (Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>)
Список pgsql-hackers
At Tue, 28 Dec 2021 08:26:28 +0530, Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com> wrote in 
> On Fri, Dec 24, 2021 at 5:54 PM Bharath Rupireddy
> <bharath.rupireddyforpostgres@gmail.com> wrote:
> >
> > On Fri, Dec 24, 2021 at 5:42 PM Michael Paquier <michael@paquier.xyz> wrote:
> > >
> > > On Fri, Dec 24, 2021 at 02:51:34PM +0900, Kyotaro Horiguchi wrote:
> > > > I thougt about something like the following, but your proposal may be
> > > > clearer.
> > >
> > > +    "LSN=%X/%X, REDO LSN=%X/%X",
> > > This could be rather confusing for the average user, even if I agree
> > > that this is some information that only an advanced user could
> > > understand.  Could it be possible to define those fields in a more
> > > deterministic way?  For one, it is hard to understand the relationship
> > > between both fields without looking at the code, particulary if both
> > > share the same value.  It is at least rather..  Well, mostly, easy to
> > > guess what each other field means in this context, which is not the
> > > case of what you are proposing here.  One idea could be use also
> > > "start point" for REDO, for example.
> >
> > How about "location=%X/%X, REDO start location=%X/%X"? The entire log
> > message can look like below:
..
> Thoughts?

It seems to me "LSN" or just "location" is more confusing or
mysterious than "REDO LSN" for the average user. If we want to avoid
being technically too detailed, we would use just "start LSN=%X/%X,
end LSN=%X/%X".  And it is equivalent to "WAL range=[%X/%X, %X/%X]"..

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Melanie Plageman
Дата:
Сообщение: Re: pg_stat_bgwriter.buffers_backend is pretty meaningless (and more?)
Следующее
От: Julien Rouhaud
Дата:
Сообщение: Re: ICU for global collation