>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 = Transaction - commits get logged
> > Mask 8 = Flush & INSERTs get logged
>
> I see no value in reverting Neil's change. The above looks way too
much
> like old-line assembler-programmer thinking to me, anyway. Why not
> invent a separate, appropriately named boolean variable for each thing
> you want to control? Even C programmers manage to avoid doing the
sort
> of mental arithmetic that the above would force onto DBAs.
>
> As for whether it should be #ifdef'd or not, I'd have no objection to
> turning WAL_DEBUG on by default in pg_config_manual.h for the duration
> of PITR development. One should not however confuse short-term
> debugging needs with features that the average user is going to need
> indefinitely. (It was not too long ago that there was still debugging
> code for btree index building in there, for crissakes.)
...erm, I guess you didn't like that one then? ;}
> As for whether it should be #ifdef'd or not, I'd have no objection to
> turning WAL_DEBUG on by default in pg_config_manual.h for the duration
> of PITR development.
Yes OK, thank you.
> Why not
> invent a separate, appropriately named boolean variable for each thing
> you want to control?
Yes, OK, will do.
Best Regards, Simon Riggs
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
