Simon Riggs wrote:
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
I've so far added an LWLock that makes replay and queries mutually
exclusive, Simple testcases seem to work, but I haven't really
beaten the system yet...
Of course, my current version falls over as soon as you do
DDL on the master - working on fixing that, and on
subsequently removing that lock again :-)
greetings, Florian Pflug
---------------------------(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