On Sun, Jun 10, 2012 at 11:41 PM, Amit Kapila amit.kap...@huawei.com 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
On Sat, Jun 9, 2012 at 1:43 AM, Amit kapila amit.kap...@huawei.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
On Sat, Jun 9, 2012 at 10:49 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@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
the code consider page with all zero's as uninitialized or the comment
is not
appropriate.
-Original Message-
From: Robert Haas [mailto:robertmh...@gmail.com]
Sent: Sunday, June 10, 2012 7:14 PM
To: Amit kapila
Cc: Tom Lane; pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] log_newpage
Robert Haas robertmh...@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
On Thu, Jun 7, 2012 at 8:06 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com 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
Robert Haas robertmh...@gmail.com writes:
On Thu, Jun 7, 2012 at 8:06 PM, Tom Lane t...@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
On Fri, Jun 8, 2012 at 9:33 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Thu, Jun 7, 2012 at 8:06 PM, Tom Lane t...@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.
On Fri, Jun 8, 2012 at 9:56 AM, Robert Haas robertmh...@gmail.com 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
On Fri, Jun 8, 2012 at 1:20 PM, Robert Haas robertmh...@gmail.com wrote:
On Fri, Jun 8, 2012 at 9:56 AM, Robert Haas robertmh...@gmail.com 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
] log_newpage header comment
On Fri, Jun 8, 2012 at 9:56 AM, Robert Haas robertmh...@gmail.com 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
Robert Haas robertmh...@gmail.com 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
12 matches
Mail list logo
