Hi,
> We can't accept patches just based on a pointer to a web site. Please
> e-mail this to the mailing list so that it can be considered a
> submission under the project's licensing terms.
>
> > I hope this would be committable and the final version.
> >
>
> PostgreSQL has high standards for code submissions. Extremely few
> submissions are committed without significant revisions to them based on
> code review. So far you've gotten a first round of high-level design
> review, there's several additional steps before something is considered
> for a commit. The whole process is outlined at
> http://wiki.postgresql.org/wiki/Submitting_a_Patch
OK, I would do so for my next patch.
> From a couple of minutes of reading the patch, the first things that
> pop out as problems are:
>
> -All of the ControlFile -> controlFile renaming has add a larger
> difference to ReadControlFile than I would consider ideal.
I think so too, I will consider this again.
> -Touching StrategyControl is not something this patch should be doing.
Sorry, I could not get this. Could you describe this?
I think StrategyControl needs to be adjusted if shared_buffers setting
was changed.
> -I don't think your justification ("debugging or portability") for
> keeping around your original code in here is going to be sufficient to
> do so.
> -This should not be named enable_buffer_cache_hibernation. That very
> large diff you ended up with in the regression tests is because all of
> the settings named enable_* are optimizer control settings. Using the
> name "buffer_cache_hibernation" instead would make a better starting point.
OK, how about `buffer_cache_hibernation_level'?
The value 0 to disable(default), 1 for saving buffer descriptors only,
2 for saving buffer descriptors and buffer blocks.
> From a bigger picture perspective, this really hasn't addressed any of
> my comments about shared_buffers only being the beginning of the useful
> cache state to worry about here. I'd at least like the solution to the
> buffer cache save/restore to have a plan for how it might address that
> too one day. This project is also picky about only committing code that
> fits into the long-term picture for desired features.
My simple motivation on this is that `We don't want to restart our DB
server because the DB buffer cache will be lost and the DB server
needs to start its operations with zero cache. Does any DBMS product
support holding the contents of DB cache as it is even by restarting,
just like the hibernation feature of PC?'.
It's very simple and many of DB admins will be happy soon with this
feature, I think.
Thanks
