Skip site navigation (1) Skip section navigation (2)

Re: log_newpage header comment

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Amit kapila <amit(dot)kapila(at)huawei(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: log_newpage header comment
Date: 2012-06-10 13:44:17
Message-ID: CA+TgmoZrrQ_nFSvXYcsYS+DDSRicaDHELvQgmatvTu=-MkQzag@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Sat, Jun 9, 2012 at 1:43 AM, Amit kapila <amit(dot)kapila(at)huawei(dot)com> wrote:
>>On further review, I think that we ought to make MarkBufferDirty() the
>>caller's job, because sometimes we may need to xlog only if
>>XLogIsNeeded(), but the buffer's got to get marked dirty either way.
>
> Incase the place where Xlog is not required, woudn't it fsync the data;
> So in that case even MarkBufferDirty() will also be not required.

Uh... no.  The whole point of doing things in shared buffers is that
you don't have to write and fsync the buffers immediately.  Instead,
buffer evicting handles that stuff for you.

>>So I think the new function should just do step 5 - emit XLOG and set
>>LSN/TLI.
>
> In the API log_newpage_buffer(), as buffer already contains the page to be logged, so can't it be assumed that the page will be initialized and no need to check
> if PageIsNew before setting LSN/TLI.

I don't see why it's any different from log_newpage() in that regard.
That data is initialized before being written, as well, but someone
contemplated the possible need to write a page of all zeros.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

pgsql-hackers by date

Next:From: Robert HaasDate: 2012-06-10 13:55:07
Subject: Re: log_newpage header comment
Previous:From: Robert HaasDate: 2012-06-10 13:41:16
Subject: Re: Ability to listen on two unix sockets

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group