On Sun, 2007-07-22 at 19:58 +0200, Florian G. Pflug wrote:
> Tom Lane wrote:
> > "Florian G. Pflug" <fgp@phlo.org> writes:
> >> I'm currently working on correctly flushing the
> >> catalog/relation/sgmr caches on a readonly PITR
> >> slave during recovery.
> >
> > I don't believe there is any workable solution to that short of logging
> > cache-flush operations in WAL.
> The reason that I dislike WAL-logging of the flush operations so much is
> that it since peopel are concerned about the amount of wal traffic
> postgres generated, such a solution would introduce yet another GUC.
> And to make this reasonable foolproof, the slave would need a way to
> detect if that GUC is set correctly on the master. All in all, that
> seems to be quite hackish...
Seems like we should WAL log flush operations first. It's fairly
straightforward to do that and we can then measure its effect on the
primary easily enough. Your other suggestions seem much more complex.
I think we have a reasonable tolerance for increases in WAL and as you
said earlier, we may balance that out with other optimisations. Or we
may find a more efficient way of doing it later.
Let's aim to get that first query running, then go back and tune it
later.
-- Simon Riggs EnterpriseDB http://www.enterprisedb.com