Re: Function to track shmem reinit time

2020-04-10 Thread Kyotaro Horiguchi
FWIW, I don't object for adding the feature like this (in other words +1), since I see the advantages Alex mentioned is valid. (Even though most of our customers notices server restart by client disconnections..) At Wed, 8 Apr 2020 11:49:11 -0400, David Steele wrote in > On 2/24/20 10:57 PM,

Re: Function to track shmem reinit time

2020-04-08 Thread David Steele
On 2/24/20 10:57 PM, Robert Haas wrote: On Sat, Feb 22, 2020 at 10:31 PM Tom Lane wrote: I'm still going to object to it, on the grounds that (1) it's exposing an implementation detail that clients should not be concerned with, and that we might change in future. The name isn't even well

Re: Function to track shmem reinit time

2020-02-24 Thread Robert Haas
On Sat, Feb 22, 2020 at 10:31 PM Tom Lane wrote: > I'm still going to object to it, on the grounds that > > (1) it's exposing an implementation detail that clients should not be > concerned with, and that we might change in future. The name isn't > even well chosen --- if the argument is that

Re: Function to track shmem reinit time

2020-02-22 Thread Alexander Korotkov
On Sat, Feb 22, 2020 at 8:01 PM Tom Lane wrote: > Alexander Korotkov writes: > > From my point of view criticism of this patch was addressed by > > argument, that pg_shmem_init_time() allows to calculate the server > > uptime [1]. This is very basic information, which is reasonable to > > get

Re: Function to track shmem reinit time

2020-02-22 Thread Tom Lane
Alexander Korotkov writes: > From my point of view criticism of this patch was addressed by > argument, that pg_shmem_init_time() allows to calculate the server > uptime [1]. This is very basic information, which is reasonable to > get without log files parsing. It's more than year since [1] is

Re: Function to track shmem reinit time

2020-02-22 Thread Alexander Korotkov
On Sun, Dec 23, 2018 at 11:14 PM Alexander Korotkov wrote: > On Tue, Apr 10, 2018 at 8:58 PM Robert Haas wrote: > > On Tue, Apr 10, 2018 at 9:07 AM, David Steele 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

Re: Function to track shmem reinit time

2018-12-23 Thread Alexander Korotkov
On Tue, Apr 10, 2018 at 8:58 PM Robert Haas wrote: > On Tue, Apr 10, 2018 at 9:07 AM, David Steele 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

Re: Function to track shmem reinit time

2018-04-10 Thread Robert Haas
On Tue, Apr 10, 2018 at 9:07 AM, David Steele 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. >> >>

Re: Function to track shmem reinit time

2018-04-10 Thread David Steele
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. Regards,

Re: Function to track shmem reinit time

2018-03-29 Thread Tomas Vondra
On 03/28/2018 08:55 PM, David Steele wrote: > On 3/4/18 11:17 AM, Tomas Vondra wrote: >> >> Furthermore, the patch is yet another victim of fd1a421fe - fixing the >> pg_proc entries is trivial, but a new version is needed. >> >> I'd also like to see an example/explanation how this improves this

Re: Function to track shmem reinit time

2018-03-28 Thread David Steele
On 3/4/18 11:17 AM, Tomas Vondra wrote: > > Furthermore, the patch is yet another victim of fd1a421fe - fixing the > pg_proc entries is trivial, but a new version is needed. > > I'd also like to see an example/explanation how this improves this > situation compared to only having

Re: Function to track shmem reinit time

2018-03-12 Thread Grigory Smolkin
On 03/03/2018 09:00 PM, Peter Eisentraut wrote: I find this premise a bit dubious. Why have a log file if it's too big to find anything in it? Server crashes aren't the only thing people are interested in. So we'll need a function for "last $anything". Thank you for your interest in this

Re: Function to track shmem reinit time

2018-03-04 Thread Tomas Vondra
On 02/28/2018 01:11 PM, Anastasia Lubennikova wrote: > > This new function can be periodiacally called by a monitoring agent, > and, if /shmem_init_time/ doesn't match /pg_postmaster_start_time,/ > we know that server crashed-restarted, and also know the exact time, > when. > Actually, after

Re: Function to track shmem reinit time

2018-03-04 Thread Tom Lane
Tomas Vondra writes: > On 02/28/2018 02:39 PM, Grigory Smolkin wrote: >> It can be used to accurately calculate server uptime, since you can`t >> rely on pg_postmaster_start_time() in this. > Can you please explain why pg_postmaster_start_time can't be used for >

Re: Function to track shmem reinit time

2018-03-04 Thread Tomas Vondra
On 02/28/2018 01:11 PM, Anastasia Lubennikova wrote: > Attached patch introduces a new function pg_shmem_init_time(), > which returns the time shared memory was last (re)initialized. > It is created for use by monitoring tools to track backend crashes. > > Currently, if the 'restart_after_crash'

Re: Function to track shmem reinit time

2018-03-04 Thread Tomas Vondra
On 02/28/2018 02:39 PM, Grigory Smolkin wrote: > It can be used to accurately calculate server uptime, since you can`t > rely on pg_postmaster_start_time() in this. > Can you please explain why pg_postmaster_start_time can't be used for this purpose? It seems like a pretty good match,

Re: Function to track shmem reinit time

2018-03-03 Thread Justin Pryzby
On Sat, Mar 03, 2018 at 01:00:52PM -0500, Peter Eisentraut wrote: > On 2/28/18 07:11, Anastasia Lubennikova wrote: > > Currently, if the 'restart_after_crash' option is on, postgres will just > > restart. > > And the only way to know that it happened is to regularly parse logfile > > or monitor

Re: Function to track shmem reinit time

2018-03-03 Thread Peter Eisentraut
On 2/28/18 07:11, Anastasia Lubennikova wrote: > Currently, if the 'restart_after_crash' option is on, postgres will just > restart. > And the only way to know that it happened is to regularly parse logfile > or monitor it, catching restart messages. This approach is really > inconvenient for >

Re: Function to track shmem reinit time

2018-02-28 Thread Grigory Smolkin
It can be used to accurately calculate server uptime, since you can`t rely on pg_postmaster_start_time() in this. On 02/28/2018 03:11 PM, Anastasia Lubennikova wrote: Attached patch introduces a new function pg_shmem_init_time(), which returns the time shared memory was last (re)initialized.

Function to track shmem reinit time

2018-02-28 Thread Anastasia Lubennikova
Attached patch introduces a new function pg_shmem_init_time(), which returns the time shared memory was last (re)initialized. It is created for use by monitoring tools to track backend crashes. Currently, if the 'restart_after_crash' option is on, postgres will just restart. And the only way