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

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: Andres Freund <andres(at)anarazel(dot)de>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, "Tsunakawa, Takayuki" <tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(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-11-23 09:15:35
Message-ID: CABUevEziCi6Cq5nJ5OnqtmTsKATFbYJT6wegj-NFU5PMiCTxAg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Nov 22, 2016 at 10:26 PM, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
wrote:

> Andres Freund wrote:
> > On 2016-11-22 16:15:58 -0500, Tom Lane wrote:
>
> > > Maybe a workable compromise would be to leave the file present, and
> have
> > > the stats collector re-write it every (say) five minutes. Then I'd be
> > > okay with having an immediate shutdown skip writing the file; you'd be
> > > losing up to five minutes' worth of activity, but not going completely
> > > nuts. So the stats collector's normal activities would include writing
> > > the temp file on-demand and the permanent file on a timed cycle.
> > >
> > > The other components of the fix (deleting on PITR rewind or stats
> > > collector crash) would remain the same.
>
> +1
>
> > It could even make sense to WAL log the contents of the stats file at
> > checkpoint (or similar) time. Then it'd be sane after crash recovery,
> > including starting from an old base backup. Loosing the information
> > about what to vacuum / analyze after a failover is quite problematic...
>
> An idea worth considering. This would also mean the file is valid in a
> standby -- the lack of the file is currently a problem if you promote
> the standby, as I recall. But the file is perhaps too large to write to
> WAL on every checkpoint.
>

There's also the consideration of what to do with stats *on the standby*.
If we WAL log the stats file, then when it replays onthe standby, the stats
there will be overwritten. And stats like number of index vs seq scans on
the standby are still interesting and would be lost.

That's not to say that I don't agree with the issues of failover vs
autovacuum. But let's try to find a way that doesn't hurt other things to
get there. But that could just be part of how we deal with the replay of it.

--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Karl O. Pinc 2016-11-23 09:21:05 Re: Patch to implement pg_current_logfile() function
Previous Message Andres Freund 2016-11-23 08:33:51 Re: Performance degradation in Bitmapscan (commit 75ae538bc3168bf44475240d4e0487ee2f3bb376)