Re: [PERFORM] WAL Optimisation - configuration and usage

>Neil Conway
> Simon Riggs wrote:
> >>Josh Berkus wrote
> >>
> >>>Simon Riggs wrote
> >>>Please set WAL_DEBUG to 1 so we can see a bit more info: thanks.
> >>
> >>I'm pretty sure that WAL_DEBUG requires a compile-time option.
> >
> > I'm surprised, but you are right, the manual does SAY this requires
a
> > compile time option; it is unfortunately not correct.
>
> Actually, the manual is correct: in 7.4 and earlier releases, enabling
> wal_debug can be done without also setting a compile-time #ifdef. As
> of current CVS HEAD, the WAL_DEBUG #ifdef must be defined before this
> variable is available.

Touche! I stand corrected, thank you both. My suggestion does work for
Rob, then.

[This also implies I have a screwed version on my machine, so thank you
also for flushing that lurking issue out for me. I'd had a suspicion for
a few weeks. Lucky I'm still just prototyping.]

On the other hand, I was just about to change the wal_debug behaviour to
allow better debugging of PITR features as they're added. I think it is
very important to be able to put the system fairly easily into debug
mode; a recompile is easy enough, but it would be even better to avoid
this completely. This would mean reversing the change you describe:
here's the design:

The behaviour I wish to add is:
Keep wal_debug as a value between 0 and 16.
If =0 then no debug output (default).
Use following bitmasks against the value
Mask 1 = XLOG Checkpoints get logged
Mask 2 = Archive API calls get logged
Mask 4 = Transaction - commits get logged
Mask 8 = Flush & INSERTs get logged

That way it should be fairly straightforward to control the amount and
type of information available to administrators. The existing design
produces too much info to be easily usable, mostly requiring a perl
program to filter out the info overload and do record counts. This
suggested design allows you to control the volume of messages, since the
bitmasks are arranged in volume/frequency order and brings the wal_debug
option back into something useful for problem diagnosis on live systems,
not just hacking the code.

Anybody object to these mods, or have better/different ideas? Getting
the diagnostics right is fairly important, IMHO, to making PITR become
real.

Best regards, Simon Riggs