Re: Function to track shmem reinit time

From: Grigory Smolkin <g(dot)smolkin(at)postgrespro(dot)ru>
To: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Function to track shmem reinit time
Date: 2018-02-28 13:39:05
Message-ID: d2a8af68-8e7c-22ef-59a8-238c05bd2a37@postgrespro.ru
Views: Raw Message | Whole Thread | Download mbox
Thread:
Lists: pgsql-hackers

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.
> 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 know that it happened is to regularly parse logfile
> or monitor it, catching restart messages. This approach is really
> inconvenient for
> users, who have gigabytes of logs.
>
> 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.
>
> Also, working on this patch, I noticed a bit of dead code
> and some discordant comments in postmaster.c.
> I see no reason to leave it as is.
> So there is a small remove_dead_shmem_reinit_code_v0.patch.
>
> --
> Anastasia Lubennikova
> Postgres Professional:http://www.postgrespro.com
> The Russian Postgres Company

--
Grigory Smolkin
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Grigory Smolkin 2018-02-28 13:50:17 Re: Reopen logfile on SIGHUP
Previous Message Amit Kapila 2018-02-28 13:32:47 Re: Contention preventing locking