Re: [RFC] Should we fix postmaster to avoid slow shutdown? - Mailing list pgsql-hackers

From Andres Freund
Subject Re: [RFC] Should we fix postmaster to avoid slow shutdown?
Date
Msg-id 20161122205512.6tqvebfgpd6uta2i@alap3.anarazel.de
Whole thread Raw
In response to Re: [RFC] Should we fix postmaster to avoid slow shutdown?  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: [RFC] Should we fix postmaster to avoid slow shutdown?  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Hi,

On 2016-11-22 15:49:27 -0500, Robert Haas wrote:
> I think you are almost right.  When the server is running, there are
> files in pg_stat_tmp but not pg_stat; when it is shut down, there are
> files in pg_stat but not pg_stat_tmp.  Of course the data can never be
> ONLY in the collector's backend-local memory because then nobody else
> could read it.

> I don't actually really understand the reason for this distinction.

pg_stat_tmp commonly is placed on tmpfs/a ramdisk.


But I'm a bit confused too - does this make any sort of difference?
Because the startup path for crash recovery is like this:

void
StartupXLOG(void)
{
.../* REDO */if (InRecovery){
...    /*     * Reset pgstat data, because it may be invalid after recovery.     */    pgstat_reset_all();

so it seems quite inconsequential whether we write out pgstat, because
we're going to nuke it either way after an immediate shutdown?

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Corey Huinker
Date:
Subject: Re: dblink get_connect_string() passes FDW option "updatable" to the connect string, connection fails.
Next
From: Tom Lane
Date:
Subject: Re: [RFC] Should we fix postmaster to avoid slow shutdown?