Hi all thanks, I have tried to fix all of the comments given above with some more code cleanups.
On Wed, Feb 22, 2017 at 6:28 AM, Robert Haas <robertmh...@gmail.com> wrote: > I think it's OK to treat that as something of a corner case. There's > nothing to keep you from doing that today: just use pg_buffercache to > dump a list of blocks on one server, and then pass those blocks to > pg_prewarm on another server. The point of this patch, AIUI, is to > automate a particularly common case of that, which is to dump before > shutdown and load upon startup. It doesn't preclude other things that > people want to do. > > I suppose we could have an SQL-callable function that does an > immediate dump (without starting a worker). That wouldn't hurt > anything, and might be useful in a case like the one you mention. In the latest patch, I have moved the things back as in old ways there will be one bgworker "auto pg_prewarm" which automatically records information about blocks which were present in buffer pool before server shutdown and then prewarm the buffer pool upon server restart with those blocks. I have reverted back the code which helped us to launch the stopped "auto pg_prewarm" bgworker. The reason I introduced a launcher SQL utility function is the running auto pg_prewarm can be stopped by the user by setting dump_interval to -1. So if the user wants to restart the stopped auto pg_prewarm(this time dump only to prewarm on next restart), he can use that utility. The user can launch the auto pg_prewarm to dump periodically while the server is still running. If that was not the concern I think I misunderstood the comments and overdid the design. So as a first patch I will keep the things simple. Also, using a separate process for prewarm and dump activity was a bad design hence reverted back same. The auto pg_prewarm can only be launched by preloading the library. And I can add additional utilities, once we can formalize what is really needed out of it. -- Thanks and Regards Mithun C Y EnterpriseDB: http://www.enterprisedb.com
Description: Binary data
-- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers