Re: Proposing pg_hibernate - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Proposing pg_hibernate
Date
Msg-id 20140604060848.GX24145@awork2.anarazel.de
Whole thread Raw
In response to Re: Proposing pg_hibernate  (Amit Kapila <amit.kapila16@gmail.com>)
Responses Re: Proposing pg_hibernate  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On 2014-06-04 10:24:13 +0530, Amit Kapila wrote:
> On Tue, Jun 3, 2014 at 5:43 PM, Gurjeet Singh <gurjeet@singh.im> wrote:
> > On Tue, Jun 3, 2014 at 7:57 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> > > It seems like it would be best to try to do this at cluster startup
> > > time, rather than once recovery has reached consistency.  Of course,
> > > that might mean doing it with a single process, which could have its
> > > own share of problems.  But I'm somewhat inclined to think that if
> > > recovery has already run for a significant period of time, the blocks
> > > that recovery has brought into shared_buffers are more likely to be
> > > useful than whatever pg_hibernate would load.
> >
> > I am not absolutely sure of the order of execution between recovery
> > process and the BGWorker, but ...
> >
> > For sizeable shared_buffers size, the restoration of the shared
> > buffers can take several seconds.
> 
> Incase of recovery, the shared buffers saved by this utility are
> from previous shutdown which doesn't seem to be of more use
> than buffers loaded by recovery.

Why? The server might have been queried if it's a hot standby one?

Greetings,

Andres Freund

-- Andres Freund                       http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: idle_in_transaction_timeout
Next
From: Amit Langote
Date:
Subject: Need to backpatch 2985e16 to 9.3 and further (HS regression test out)