Re: [HACKERS] sync process names between ps and pg_stat_activity
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] sync process names between ps and pg_stat_activity |
Дата | |
Msg-id | 5525.1505874018@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] sync process names between ps and pg_stat_activity (Michael Paquier <michael.paquier@gmail.com>) |
Список | pgsql-hackers |
Michael Paquier <michael.paquier@gmail.com> writes: > On Fri, Sep 1, 2017 at 5:33 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes: >>> As an aside, is there a reason why the archiver process is not included >>> in pg_stat_activity? >> It's not connected to shared memory. > Do you think that monitoring would be a reason sufficient to do so? My > personal opinion on the matter is that people are more and more going > to move on with pull (*) models (aka pg_receivewal and such with > replication slots) instead of push (*) models (use of > archive_command), so that monitoring of the archiver becomes less and > less useful in the long-term. And there is also pg_stat_archiver that > covers largely the gap for archive failures. Meh. I think keeping it separate from shared memory is a good thing for reliability reasons. > Still, one reason that could be used to connect it to shared memory is > to control the interval of time used for archive attempts, which is > now a interval hardcoded of 1s in pgarch_ArchiverCopyLoop(). Here more > flexibility would be definitely useful. AFAIR, GUC reloads work regardless of that. If we wanted to make the interval configurable, this would not prevent us from doing so. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
В списке pgsql-hackers по дате отправления: