On Tue, Feb 7, 2017 at 12:24 PM, Amit Kapila <amit.kapil...@gmail.com> wrote: > On Tue, Feb 7, 2017 at 11:53 AM, Beena Emerson <memissemer...@gmail.com> > wrote: >> Are 2 workers required? >> > > I think in the new design there is a provision of launching the worker > dynamically to dump the buffers, so there seems to be a need of > separate workers for loading and dumping the buffers. However, there > is no explanation in the patch or otherwise when and why this needs a > pair of workers. Also, if the dump interval is greater than zero, > then do we really need to separately register a dynamic worker?
We have introduced a new value -1 for pg_prewarm.dump_interval this means we will not dump at all, At this state, I thought auto pg_prewarm process need not run at all, so I coded to exit the auto pg_prewarm immediately. But If the user decides to start the auto pg_prewarm to dump only without restarting the server, I have introduced a launcher function "launch_pg_prewarm_dump" to restart the auto pg_prewarm only to dump. Since now we can launch worker only to dump, I thought we can redistribute the code between two workers, one which only does prewarm (load only) and another dumps periodically. This helped me to modularize and reuse the code. So once load worker has finished its job, it registers a dump worker and then exists. But if max_worker_processes is not enough to launch the "auto pg_prewarm dump" bgworker We throw an error 2017-02-07 14:51:59.789 IST [50481] ERROR: registering dynamic bgworker "auto pg_prewarm dump" failed c 2017-02-07 14:51:59.789 IST [50481] HINT: Consider increasing configuration parameter "max_worker_processes". Now thinking again instead of such error and then correcting same by explicitly launching the auto pg_prewarm dump bgwroker through launch_pg_prewarm_dump(), I can go back to original design where there will be one worker which loads and then dumps periodically. And launch_pg_prewarm_dump will relaunch dump only activity of that worker. Does this sound good? -- Thanks and Regards Mithun C Y EnterpriseDB: http://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
