On Sun, 2006-07-16 at 12:40 -0400, Tom Lane wrote:
> A compromise that might be good enough is to add an rmgr routine defined
> as "bool is_idle(void)" that tests whether the rmgr has any open state
> to worry about. Then, recovery checkpoints are done only if all rmgrs
> say they are idle.
Like it.
> That is, we only checkpoint if there is not a need
> for any state files. At least for btree's usage, this should be all
> right since the "split pending" state is short-lived and so most of the
> time we'd not need to skip checkpoints. I'm not totally sure about GIST
> or GIN though (Teodor?).
Considering how infrequently we wanted to do recovery checkpoints, this
is unlikely to cause any issue. But in any case, this is the best we can
give people, rather than a compromise.
Perhaps that should be extended to say whether there are any
non-idempotent changes made in the last checkpoint period. That might
cover a wider set of potential actions.
If index splits in GIST or GIN are *not* short lived, then I would
imagine we'd have some serious contention problems to clear up since an
inconsistent index is unusable and would require portions of it to be
locked throughout such operations to ensure their atomicity.
-- Simon Riggs EnterpriseDB http://www.enterprisedb.com