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, Ro
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 chos
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 it'
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 wi
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
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 entry
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 sh
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.
>>
>> Fine with me.
>
> This e
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,
--
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
>
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 pg_postmaster_st
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 to
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
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
> this purpose? It seems like a pre
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' o
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, considerin
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 it,
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
> use
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.
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 to
20 matches
Mail list logo
