On Tue, Apr 10, 2018 at 8:58 PM Robert Haas <robertmh...@gmail.com> wrote: > On Tue, Apr 10, 2018 at 9:07 AM, David Steele <da...@pgmasters.net> wrote: > > On 3/29/18 9:40 AM, Tomas Vondra wrote: > >> On 03/28/2018 08:55 PM, David Steele wrote: > >>> I'm setting this entry to Waiting on Author, but based on the discussion > >>> I think it should be Returned with Feedback. > >> > >> Fine with me. > > > > This entry has been marked Returned with Feedback. > > I guess I'm in the minority here, but I don't see why it isn't useful > to have something like this. It's a lot easier for a monitoring > process to poll for this kind of thing than it is to monitor the logs. > Not that log monitoring isn't a good idea, but this is pretty > lightweight.
+1, I think the issue this patch is addressing is that PostgreSQL now doesn't have true uptime function. We now recommend using pg_postmaster_start_time() for uptime calculation, but that isn't it. When backed crashes, shmen is reinitialized and PostgreSQL is restarted then uptime should be reset to zero, but pg_postmaster_start_time() is not about that. The major argument against this patch I got from the thread is that we shouldn't introduce new functions exposing information, which could be already fetched from logs. However, I think following this logic we should remove pg_postmaster_start_time() too. ------ Alexander Korotkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company
