Excerpts from Tom Lane's message of mié may 04 12:44:36 -0300 2011:
> This seems like a lot of complication for rather dubious gain. What
> happens when the DBA changes the shared_buffers setting, for instance?
> How do you protect against the cached buffers getting out-of-sync with
> the actual disk files (especially during recovery scenarios)? What
> about crash-induced corruption in the cache file itself (consider the
> not-unlikely possibility that init will kill the database before it's
> had time to dump all the buffers during a system shutdown)? Do you have
> any proof that writing out a few GB of buffers and then reading them
> back in is actually much cheaper than letting the database re-read the
> data from the disk files?
I thought the idea wasn't to copy the entire buffer but only a
descriptor, so that the buffer would be loaded from the original page.
If shared_buffers changes, there's no problem. If the new setting is
smaller, then the last paages would just not be copied, and would have
to be read from disk the first time they are accessed. If the new
setting is larger, then the last few buffers would remain unused until
requested.
As for gain, I have heard of test setups requiring hours of runtime in
order to prime the buffer cache.
Crash safety would have to be researched, sure. Maybe only do it in
clean shutdown.
--
Álvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support