Re: add recovery, backup, archive, streaming etc. activity messages to server logs along with ps display
От | Euler Taveira |
---|---|
Тема | Re: add recovery, backup, archive, streaming etc. activity messages to server logs along with ps display |
Дата | |
Msg-id | 423ee949-17fd-4a17-a338-ef29852ab7c1@www.fastmail.com обсуждение исходный текст |
Ответ на | add recovery, backup, archive, streaming etc. activity messages to server logs along with ps display (Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>) |
Ответы |
Re: add recovery, backup, archive, streaming etc. activity messages to server logs along with ps display
|
Список | pgsql-hackers |
On Wed, Nov 10, 2021, at 2:38 PM, Bharath Rupireddy wrote:
As discussed in [1], isn't it a better idea to add some of activitymessages [2] such as recovery, archive, backup, streaming etc. toserver logs at LOG level? They are currently being set into ps displaywhich is good if the postgres is being run on a standalone box/VMwhere users can see the ps display, but it doesn't help much in casethe postgres is being run on a cloud environment where users don'thave access to ps display output. Moreover, the ps display istransient and will not help to analyze after an issue occurs.
Besides recovery, the other activities already provide information through
views. I might be missing something but it seems the current views already
provide the information that ps displays.
Having the above messages in the server logs will be useful tounderstand how the system is/was doing/progressing with these(sometimes time-intensive) operations.
It could be useful for a root cause analysis, however, you are also increasing
the number of LOG messages in a system that doesn't/won't require such
information. It is fine to add additional DEBUG messages if there isn't a
similar one yet. If at least the message level were module-controlled, you
could modify a setting to gather more messages from a specific module.
Unfortunately, that's not possible so we should avoid superfluous messages.
В списке pgsql-hackers по дате отправления: