Robert Haas <robertmhaas@gmail.com> writes:
> On Thu, Jun 7, 2012 at 8:06 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> AFAICS, not passing the buffer ID to XLogInsert is not an issue, since
>> we are logging the whole page in any case. �However, failing to perform
>> MarkBufferDirty within the critical section definitely is an issue.
> However, I'm not failing to do that: there's an enclosing critical section.
Mph. But is it being done in the right order relative to the other XLOG
related steps? See the code sketch in transam/README.
> So we have to write the page out immediately, then we have to XLOG it,
> and then even though we've XLOG'd it, we still have to fsync it
> immediately. It might be better to go through shared_buffers, which
> would allow the write and fsync to happen in the background.
Well, that's a fair point, but on the other hand we've not had any
complaints traceable to the cost of making init forks.
On the whole, I don't care for the idea that the
modify-and-xlog-a-buffer sequence is being split between log_newpage and
its caller. That sounds like bugs waiting to happen anytime somebody
refactors XLOG operations. It would probably be best to refactor this
as you're suggesting, so that that becomes less nonstandard.
regards, tom lane