Re: log_newpage header comment - Mailing list pgsql-hackers

From Tom Lane
Subject Re: log_newpage header comment
Date
Msg-id 28146.1339253384@sss.pgh.pa.us
Whole thread Raw
In response to Re: log_newpage header comment  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: log_newpage header comment  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> Whee, testing is fun.  Second try.

I'm concerned by the fact that neither the original nor the new code
bother to test whether the relation is WAL-loggable.  It may be that
ginbuildempty cannot be invoked for temp tables, but it still seems
like an oversight waiting to bite you.  I'd be happier if there were
a RelationNeedsWAL test here.  Come to think of it, the other
foobuildempty functions aren't checking this either.

A related point is that most of the other existing calls to log_newpage
are covered by "if (XLogIsNeeded())" tests.  It's not immediately
obvious why these two shouldn't be.  After some reflection I think
that's correct, but probably the comments for log_newpage and
log_newpage_buffer need to explain the different WAL-is-needed tests
that apply to the two usages.

(I'm also thinking that the XLogIsNeeded macro is very poorly named,
as the situations it should be used in are far more narrow than the
macro name suggests.  Haven't consumed enough caffeine to think of
a better name, though.)
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Avoiding adjacent checkpoint records
Next
From: Dean Rasheed
Date:
Subject: PATCH: Improve DROP FUNCTION hint