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