Re: Operation log for major operations
От | Dmitry Koval |
---|---|
Тема | Re: Operation log for major operations |
Дата | |
Msg-id | 5c8ab42d-d0f7-42fa-6d98-cee4649c0d6d@postgrespro.ru обсуждение исходный текст |
Ответ на | Re: Operation log for major operations (Justin Pryzby <pryzby@telsasoft.com>) |
Ответы |
Re: Operation log for major operations
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: