On Tue, Jun 3, 2014 at 7:57 AM, Robert Haas <robertmh...@gmail.com> wrote: > On Thu, May 29, 2014 at 12:12 AM, Amit Kapila <amit.kapil...@gmail.com> wrote: >>> IMHO, all of these caveats, would affect a very small fraction of >>> use-cases and are eclipsed by the benefits this extension provides in >>> normal cases. >> >> I agree with you that there are only few corner cases where evicting >> shared buffers by this utility would harm, but was wondering if we could >> even save those, say if it would only use available free buffers. I think >> currently there is no such interface and inventing a new interface for this >> case doesn't seem to reasonable unless we see any other use case of >> such a interface. > > 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. I have a feeling the users wouldn't like their master database take up to a few minutes to start accepting connections. From my tests [1], " In the 'App after Hibernator' [case] ... This took 70 seconds for reading the ~4 GB database." [1]: http://gurjeet.singh.im/blog/2014/04/30/postgres-hibernator-reduce-planned-database-down-times/ Best regards, -- Gurjeet Singh http://gurjeet.singh.im/ EDB www.EnterpriseDB.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers