Tom Lane wrote:
> Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes:
>> Tom Lane wrote:
>>> Specifically, I propose this patch instead.
>
>> It looks better, but leaves the door open for WAL insertions for a much
>> longer period. Particularly, there's the call to CheckpointGuts(), which
>> does a lot of things. Maybe I'm just too paranoid about keeping that
>> sanity check as tight as possible...
>
> Well, I'd prefer to go through the LocalSetXLogInsertAllowed/
> reset LocalXLogInsertAllowed dance twice rather than have this code
> calling InitXLOGAccess directly (and unconditionally, which was
> even worse IMHO). But I don't actually see anything wrong with
> having CheckpointGuts enabled to write WAL. I could even see that
> being *necessary* in some future iteration of the system --- who's
> to say that a checkpoint involves adding only one WAL entry?
Yeah. maybe it's OK. There isn't anything strictly wrong about writing
WAL records at that time - we already allowed it for the rmgr cleanup
routines. CheckpointGuts is shared by recovery points, though, so any
WAL insertions in there would be conditional (like "if (in recovery)
xloginsert()").
I'll commit your patch then.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com