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

Поиск
Список
Период
Сортировка
От Magnus Hagander
Тема Re: [RFC] Should we fix postmaster to avoid slow shutdown?
Дата
Msg-id CABUevEziCi6Cq5nJ5OnqtmTsKATFbYJT6wegj-NFU5PMiCTxAg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [RFC] Should we fix postmaster to avoid slow shutdown?  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Ответы Re: [RFC] Should we fix postmaster to avoid slow shutdown?
Список pgsql-hackers
On Tue, Nov 22, 2016 at 10:26 PM, Alvaro Herrera <alvherre@2ndquadrant.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.

--

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: Performance degradation in Bitmapscan (commit 75ae538bc3168bf44475240d4e0487ee2f3bb376)
Следующее
От: "Karl O. Pinc"
Дата:
Сообщение: Re: Patch to implement pg_current_logfile() function