Re: Proposing pg_hibernate - Mailing list pgsql-hackers

BGSaver is saving the buffers, now I think it is possible that it has

saved partial information (information about some buffers is correct

and others is missing) and it is also possible by that time checkpoint

record is not written (which means recovery will start from previous

restart point).  So whats going to happen is that pg_hibernate might

load some less used buffers/blocks (which have lower usage count)

and WAL replayed blocks will be sacrificed.  So the WAL data from

previous restart point and some more due to delay in start of

standby (changes occured in master during that time) will be

sacrificed.

Another case is of standalone server in which case there is always

high chance that blocks recovered by recovery are the active one's.

Now I agree that case of standalone servers is less, but still some

small applications might be using it.  Also I think same is true if

the crashed server is master.

> > I think that's essentially the same point Amit is making.  Gurjeet is
> > arguing for reloading the buffers from the previous shutdown at end of
> > recovery; IIUC, Amit, you, and I all think this isn't a good idea.
>
> I think I am actually arguing for Gurjeet's position. If the server is
> actively being queried (i.e. hot_standby=on and actually used for
> queries) it's quite reasonable to expect that shared_buffers has lots of
> content that is *not* determined by WAL replay.

Yes, that's quite possible, however there can be situations where it

is not true as explained above.

> There's not that much read IO going on during WAL replay anyway - after
> a crash/start from a restartpoint most of it is loaded via full page
> anyway.

> So it's only disadvantageous to fault in pages via pg_hibernate
> if that causes pages that already have been read in via FPIs to be
> thrown out.

So for such cases, pages loaded by pg_hibernate turn out to be loss.