Simon Riggs wrote:
> 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.
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