On Sun, 2007-07-22 at 19:58 +0200, Florian G. Pflug wrote: > Tom Lane wrote: > > "Florian G. Pflug" <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
