Function to track shmem reinit time

From: Anastasia Lubennikova <a(dot)lubennikova(at)postgrespro(dot)ru>
To: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Function to track shmem reinit time
Date: 2018-02-28 12:11:33
Message-ID: b3a85c5d-56a8-677b-5578-86d94654eb5c@postgrespro.ru
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

Attachment Content-Type Size
remove_dead_shmem_reinit_code_v0.patch text/x-patch 1.9 KB
shmem_init_time_v0.patch text/x-patch 4.3 KB

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alexander Kuzmenkov 2018-02-28 12:55:19 Re: [patch] BUG #15005: ANALYZE can make pg_class.reltuples inaccurate.
Previous Message David Rowley 2018-02-28 11:35:01 Re: [HACKERS] path toward faster partition pruning