Heikki Linnakangas <heikki@enterprisedb.com> writes:
> One thing that's missing, that I originally hoped to achieve with this,
> is logging the cause of a checkpoint. Doing that would have required
> either sprinkling elogs to all callers of RequestCheckpoint, or adding a
> "reason" parameter to it and decoding that to a log message inside
> RequestCheckpoint, which seems a bit ugly just for logging purposes.
It strikes me that we could get most of the mileage needed here just by
logging all of the "flags" bits. In particular, it would cost almost
nothing to define an extra flag bit that's set by the bgwriter when a
time-based checkpoint is triggered, and then we would have flag bits
telling us:
* time-based checkpoint
* xlog-based checkpoint
* immediate checkpoint
* shutdown checkpoint
and that would really cover pretty much everything you'd need to know.
Does anyone particularly care whether an immediate checkpoint is
triggered by CHECKPOINT, CREATE DATABASE or DROP DATABASE?
If anyone *does* care, there are plenty of leftover flag bits that we
could use to pass that info, but it seems like gilding the lily.
> Also, that would have meant printing one more log message per
> checkpoint, making it more chatty than I'd like it to be.
I'm envisioning something like
LOG: checkpoint starting: immediate force wait
where we're just adding a word to the message for each flag bit. No
more lines than you have.
regards, tom lane
