On Sun, Jun 10, 2012 at 11:41 PM, Amit Kapila wrote:
>>>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 you mean to say that there exists operations wh
a
Cc: Tom Lane; pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] log_newpage header comment
On Sat, Jun 9, 2012 at 1:43 AM, Amit kapila 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
&g
On Sat, Jun 9, 2012 at 10:49 AM, Tom Lane wrote:
> Robert Haas 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 t
On Sat, Jun 9, 2012 at 1:43 AM, Amit kapila 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 re
Robert Haas 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
-hackers@postgresql.org
Subject: Re: [HACKERS] log_newpage header comment
On Fri, Jun 8, 2012 at 9:56 AM, Robert Haas wrote:
> OK. So what I'm thinking is that we should add a new function that
> takes a relfilenode and a buffer and steps 4-6 of what's described in
> transam/README: mar
On Fri, Jun 8, 2012 at 1:20 PM, Robert Haas wrote:
> On Fri, Jun 8, 2012 at 9:56 AM, Robert Haas wrote:
>> OK. So what I'm thinking is that we should add a new function that
>> takes a relfilenode and a buffer and steps 4-6 of what's described in
>> transam/README: mark the buffer dirty, xlog it
On Fri, Jun 8, 2012 at 9:56 AM, Robert Haas wrote:
> OK. So what I'm thinking is that we should add a new function that
> takes a relfilenode and a buffer and steps 4-6 of what's described in
> transam/README: mark the buffer dirty, xlog it, and set the LSN and
> TLI. We might want to have this
On Fri, Jun 8, 2012 at 9:33 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Jun 7, 2012 at 8:06 PM, Tom Lane 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 with
Robert Haas writes:
> On Thu, Jun 7, 2012 at 8:06 PM, Tom Lane 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.
> Howe
On Thu, Jun 7, 2012 at 8:06 PM, Tom Lane wrote:
> Robert Haas writes:
>> It seems that in implementing ginbuildempty(), I falsified the first
>> "note" in the header comment for log_newpage():
>
>> * Note: all current callers build pages in private memory and write them
>> * directly to smgr, r
Robert Haas writes:
> It seems that in implementing ginbuildempty(), I falsified the first
> "note" in the header comment for log_newpage():
> * Note: all current callers build pages in private memory and write them
> * directly to smgr, rather than using bufmgr. Therefore there is no need
>
It seems that in implementing ginbuildempty(), I falsified the first
"note" in the header comment for log_newpage():
* Note: all current callers build pages in private memory and write them
* directly to smgr, rather than using bufmgr. Therefore there is no need
* to pass a buffer ID to XLogIn
13 matches
Mail list logo
