Re: Operation log for major operations

Поиск
Список
Период
Сортировка
От Kirk Wolak
Тема Re: Operation log for major operations
Дата
Msg-id CACLU5mRzPOZmZrEEnwYKsd3st_rKEhnHWq2qU0TfdtB0AzCKxg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Operation log for major operations  (Dmitry Koval <d.koval@postgrespro.ru>)
Ответы Re: Operation log for major operations  (Dmitry Koval <d.koval@postgrespro.ru>)
Список pgsql-hackers
On Thu, Mar 2, 2023 at 4:09 PM Dmitry Koval <d.koval@postgrespro.ru> wrote:
I'll try to expand my explanation.
I fully understand and accept the arguments about "limited sense to go
into the control file" and "about recording *anything* in the control
file". This is totally correct for vanilla.
But vendors have forks of PostgreSQL with custom features and extensions.
Sometimes (especially at the first releases) these custom components
have bugs which can causes rare problems in data.
These problems can migrate with using pg_upgrade and "lazy" upgrade of
pages to higher versions of PostgreSQL fork.

So in error cases "recording crash information" etc. is not the only
important information.
Very important is history of this database (pg_upgrades, promotions,
pg_resets, pg_rewinds etc.).
Often these "history" allows you to determine from which version of the
PostgreSQL fork the error came from and what causes of errors we can
discard immediately.

This "history" is the information that our technical support wants (and
reason of this patch), but this information is not needed for vanilla...

Another important condition is that the user should not have easy ways
to delete information about "history" (about reason to use pg_control
file as "history" storage, but write into it from position 4kB, 8kB,...).

--
With best regards,
Dmitry Koval

Postgres Professional: http://postgrespro.com

Dmitry, this is a great explanation.  Thinking outside the box, it feels like:
We need some kind of semaphore flag that tells us something awkward happened.
When it happened, and a little bit of extra information.

You also make the point that if such things have happened, it would probably be a good idea to NOT
allow pg_upgrade to run.  It might even be a reason to constantly bother someone until the issue is repaired.

To that point, this feels like a "postgresql_panic.log" file (within the postgresql files?)...  Something that would prevent pg_upgrade,
etc.  That everyone recognizes is serious.  Especially 3rd party vendors. 

I see the need for such a thing.  I have to agree with others about questioning the proper place to write this.

Are there other places that make sense, that you could use, especially if knowing it exists means there was a serious issue?

Kirk

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

Предыдущее
От: Dmitry Koval
Дата:
Сообщение: Re: Operation log for major operations
Следующее
От: Andrew Dunstan
Дата:
Сообщение: Re: buildfarm + meson