Re: [HACKERS] [PERFORM] WAL Optimisation - configuration and usage

2004-03-08 Thread Simon Riggs
>Tom Lane > "Simon Riggs" <[EMAIL PROTECTED]> writes: > > 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 ge

Re: [HACKERS] [PERFORM] WAL Optimisation - configuration and usage

2004-03-03 Thread Neil Conway
Simon Riggs wrote: 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. That's a development activity. Enabling the WAL_DEBUG #ifdef by default during the 7.5 development cycle would be uncontroversial, I think. I thin

Re: [HACKERS] [PERFORM] WAL Optimisation - configuration and usage

2004-03-03 Thread Tom Lane
"Simon Riggs" <[EMAIL PROTECTED]> writes: > 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 = Tran

Re: [HACKERS] [PERFORM] WAL Optimisation - configuration and usage

2004-03-03 Thread Simon Riggs
>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 requir