Re: Configuring BLCKSZ and XLOGSEGSZ (in 8.3)

On Mon, 2006-11-27 at 18:26 -0500, Tom Lane wrote:

> Sorry, but that's just handwaving. 

Thats fine. I was responding to private comments that I was trying to
test things that had not been subject to community design. My response
was that the community would react badly if conjectures are discussed
without presenting firm performance evidence. Chicken and egg...

> [ studies code a bit more... ]  I'm also wondering whether the forced
> pg_control update at each xlog seg switch is worth its keep.  Offhand it
> seems like the checkpoint pointer is enough; why are we maintaining
> logId/logSeg in pg_control?
ControlFile->logId = openLogId;ControlFile->logSeg = openLogSeg + 1;ControlFile->time =
time(NULL);UpdateControlFile();

I've looked through the code paths related to the above code just at
xlog switch. There doesn't seem to be any useful effect of storing these
values in the control file. The logId and logSeg is never read, only
written.

There is a slight impact in that when the server crashes it will say the
database crashed at ControlFile->time, so if we remove the update the
crash information will be slightly more out of date than it is now in
many cases. In the case of a long checkpoint_timeout that could be as
much as an hour, but then thats no worse than it is now potentially on a
system in a slack period when little WAL is written.

Perhaps we can say if its within a minute of the last switch time, then
we update the control file, otherwise don't. That seems like coding for
the sake of it though and if we wanted that then we'd get the bgwriter
to do it, not a random backend.

Anyway, we can skip updating the control file and its fsync. IMHO
touching the control file less is likely to make us more robust.

I'll code up a patch for that and test to see if that improves things.

Not sure if this is RC material? No, OK, don't shout.

--  Simon Riggs              EnterpriseDB   http://www.enterprisedb.com