Re: [RFC] Should we fix postmaster to avoid slow shutdown?

From: "Tsunakawa, Takayuki" <tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com>
To: 'Tom Lane' <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: 'Robert Haas' <robertmhaas(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [RFC] Should we fix postmaster to avoid slow shutdown?
Date: 2016-09-28 03:07:45
Message-ID: 0A3221C70F24FB45833433255569204D1F5F2BAC@G01JPEXMBYT05
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> From: pgsql-hackers-owner(at)postgresql(dot)org
> [mailto:pgsql-hackers-owner(at)postgresql(dot)org] On Behalf Of Tom Lane
> Allowing SIGQUIT to prompt fast shutdown of the stats collector seems sane,
> though. Try to make sure it doesn't leave partly-written stats files
> behind.

The attached patch based on HEAD does this. I'd like this to be back-patched because one of our important customers uses 9.2.

I didn't remove partially written stat files on SIGQUIT for the following reasons. Is this OK?

1. The recovery at the next restart will remove the stat files.
2. SIGQUIT processing should be as fast as possible.
3. If writing stats files took long due to the OS page cache flushing, removing files might be forced to wait likewise.

> FWIW, I'm pretty much -1 on messing with the timing of the socket close
> actions. I broke that once within recent memory, so maybe I'm gun-shy,
> but I think that the odds of unpleasant side effects greatly outweigh any
> likely benefit there.

Wasn't it related to TouchSocketFiles()? Can I see the discussion on this ML? I don't see any problem looking at the code...

Regards
Takayuki Tsunakawa

Attachment Content-Type Size
01_pgstat_avoid_writing_on_sigquit.patch application/octet-stream 3.3 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2016-09-28 04:04:51 Re: Detect supported SET parameters when pg_restore is run
Previous Message Mark Dilger 2016-09-28 02:45:30 sloppy handling of pointers