Re: Function to track shmem reinit time

From: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
To: Anastasia Lubennikova <a(dot)lubennikova(at)postgrespro(dot)ru>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Function to track shmem reinit time
Date: 2018-03-03 18:00:52
Message-ID: dea1cd67-941d-e922-6cc1-24561fa382f2@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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
> users, who have gigabytes of logs.

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".

> 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.

If we want to do something like this, I'd rather have a name that does
not expose implementation details. If we restructure shared memory
management in the future, the name won't apply anymore. Call it "last
crash" or "last reinit" or something like that.

--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Magnus Hagander 2018-03-03 18:03:04 Re: perltidy version
Previous Message Jim Finnerty 2018-03-03 17:57:53 Re: Cached/global query plans, autopreparation