On Tue, Jun 3, 2014 at 8:13 AM, Gurjeet Singh <gurj...@singh.im> wrote: > 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
Currently pg_hibernator uses ReadBufferExtended() API, and AIUI, that API requires a database connection//shared-memory attachment, and that a backend process cannot switch between databases after the initial connection. >> 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. The applications that connect to a standby may have a different access pattern than the applications that are operating on the master database. So the buffers that are being restored by startup process may not be relevant to the workload on the standby. 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
