On Wed, 2010-07-28 at 14:22 -0700, Jeff Davis wrote:
On Wed, 2010-07-28 at 15:37 -0400, Tom Lane wrote:
So nevermind that distraction. I'm back to thinking that fix1 is
the way to go.
Agreed.
It's uncontroversial to have a simple guard against corrupting an
uninitialized page, and
On Thu, Jul 29, 2010 at 4:58 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Wed, 2010-07-28 at 14:22 -0700, Jeff Davis wrote:
On Wed, 2010-07-28 at 15:37 -0400, Tom Lane wrote:
So nevermind that distraction. I'm back to thinking that fix1 is
the way to go.
Agreed.
It's uncontroversial
Robert Haas robertmh...@gmail.com writes:
On Thu, Jul 29, 2010 at 4:58 AM, Simon Riggs si...@2ndquadrant.com wrote:
Still don't understand why we would not initialize such pages. If we're
copying a relation we must know enough about it to init a page.
Well, I don't see why we'd want to do
On Wed, Jul 28, 2010 at 5:22 PM, Jeff Davis pg...@j-davis.com wrote:
On Wed, 2010-07-28 at 15:37 -0400, Tom Lane wrote:
So nevermind that distraction. I'm back to thinking that fix1 is
the way to go.
Agreed.
It's uncontroversial to have a simple guard against corrupting an
uninitialized
Robert Haas robertmh...@gmail.com writes:
Here's a version of Jeff's fix1 patch (with a trivial change to the
comment) that applies to HEAD, REL9_0_STABLE, REL8_4_STABLE, and
REL8_3_STABLE; a slightly modified version that applies to
REL8_2_STABLE; and another slightly modified version that
On Thu, Jul 29, 2010 at 11:09 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
Here's a version of Jeff's fix1 patch (with a trivial change to the
comment) that applies to HEAD, REL9_0_STABLE, REL8_4_STABLE, and
REL8_3_STABLE; a slightly modified version that
On Wed, Jul 28, 2010 at 12:23 AM, Jeff Davis pg...@j-davis.com wrote:
On Tue, 2010-07-27 at 15:23 -0700, Jeff Davis wrote:
On Tue, 2010-07-27 at 17:18 -0400, Robert Haas wrote:
My first concern with that idea was that it may create an inconsistency
between the primary and the standby. The
On Tue, 2010-07-27 at 21:23 -0700, Jeff Davis wrote:
Both potential fixes attached and both appear to work.
fix1 -- Only call PageSetLSN/TLI inside log_newpage() and
heap_xlog_newpage() if the page is not zeroed.
fix2 -- Don't call log_newpage() at all if the page is not zeroed.
Please
On Wed, Jul 28, 2010 at 7:02 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Tue, 2010-07-27 at 21:23 -0700, Jeff Davis wrote:
Both potential fixes attached and both appear to work.
fix1 -- Only call PageSetLSN/TLI inside log_newpage() and
heap_xlog_newpage() if the page is not zeroed.
On Wed, 2010-07-28 at 06:40 -0400, Robert Haas wrote:
fix1 -- Only call PageSetLSN/TLI inside log_newpage() and
heap_xlog_newpage() if the page is not zeroed.
fix2 -- Don't call log_newpage() at all if the page is not zeroed.
Please review. I don't have a strong opinion about which one
Jeff Davis pg...@j-davis.com writes:
However, when Simon said We definitely shouldn't do anything that
leaves standby different to primary. you said obviously. Fix2 can
leave a difference between the two, because zeroed pages at the end of
the heap file on the primary will not be sent to the
On Wed, 2010-07-28 at 12:36 -0400, Tom Lane wrote:
Jeff Davis pg...@j-davis.com writes:
However, when Simon said We definitely shouldn't do anything that
leaves standby different to primary. you said obviously. Fix2 can
leave a difference between the two, because zeroed pages at the end of
On Wed, Jul 28, 2010 at 12:36 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Jeff Davis pg...@j-davis.com writes:
However, when Simon said We definitely shouldn't do anything that
leaves standby different to primary. you said obviously. Fix2 can
leave a difference between the two, because zeroed pages
On Wed, 2010-07-28 at 13:18 -0400, Robert Haas wrote:
In Jeff's original example, he crashes the database
after extending the relation but before initializing and writing the
new page. I believe that at that point no XLOG has been written yet,
so the relation has been extended but there is no
Robert Haas robertmh...@gmail.com writes:
On Wed, Jul 28, 2010 at 12:36 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I understand it, and I don't like it one bit. I haven't caught up on
this thread yet, but I think the only acceptable solution is one that
leaves the slave in the *same* state as the
On Wed, Jul 28, 2010 at 2:21 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Wed, Jul 28, 2010 at 12:36 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I understand it, and I don't like it one bit. I haven't caught up on
this thread yet, but I think the only
On Wed, 2010-07-28 at 14:50 -0400, Robert Haas wrote:
It seems like if log_newpage() were to set the LSN/TLI before calling
XLogInsert() - or optionally not - then it wouldn't be necessary to
set them also in heap_xlog_newpage(); the memcpy operation would by
definition have copied the right
On Wed, Jul 28, 2010 at 3:08 PM, Jeff Davis pg...@j-davis.com wrote:
On Wed, 2010-07-28 at 14:50 -0400, Robert Haas wrote:
It seems like if log_newpage() were to set the LSN/TLI before calling
XLogInsert() - or optionally not - then it wouldn't be necessary to
set them also in
Robert Haas robertmh...@gmail.com writes:
On Wed, Jul 28, 2010 at 2:21 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I've caught up on the thread now, and I think that fix2 (skip logging
the page) is extremely dangerous and has little if anything in its
favor.
Why do you think that? They will be
I wrote:
I think it is appropriate to be setting the LSN/TLI in the case of a
page that's been constructed by the caller as part of the WAL-logged
action, but doing so in copy_relation_data seems rather questionable.
BTW, I thought of an argument that explains why that's sane: it marks
the
On Wed, Jul 28, 2010 at 3:16 PM, Tom Lane t...@sss.pgh.pa.us wrote:
(1) You're assuming that the page will be zeroes on the slave without
having forced it to be so. A really obvious case where this fails
is where we're doing crash-and-restart on the master: a later action
could have modified
On Wed, 2010-07-28 at 15:37 -0400, Tom Lane wrote:
So nevermind that distraction. I'm back to thinking that fix1 is
the way to go.
Agreed.
It's uncontroversial to have a simple guard against corrupting an
uninitialized page, and uncontroversial is good for things that will be
back-patched.
On Tue, Jul 27, 2010 at 2:06 PM, Jeff Davis pg...@j-davis.com wrote:
I reported a problem here:
http://archives.postgresql.org/pgsql-bugs/2010-07/msg00173.php
Perhaps I used a poor subject line, but I believe it's a serious issue.
That reproducible sequence seems like an obvious bug to me on
On Tue, 2010-07-27 at 15:50 -0400, Robert Haas wrote:
1. Have log_newpage() and heap_xlog_newpage() only call PageSetLSN() and
PageSetTLI() if the page is not new. This seems slightly awkward because
most WAL replay stuff doesn't have to worry about zero pages, but in
this case I think it
On Tue, Jul 27, 2010 at 5:08 PM, Jeff Davis pg...@j-davis.com wrote:
On Tue, 2010-07-27 at 15:50 -0400, Robert Haas wrote:
1. Have log_newpage() and heap_xlog_newpage() only call PageSetLSN() and
PageSetTLI() if the page is not new. This seems slightly awkward because
most WAL replay stuff
On Tue, 2010-07-27 at 17:18 -0400, Robert Haas wrote:
My first concern with that idea was that it may create an inconsistency
between the primary and the standby. The primary could have a bunch of
zero pages that never make it to the standby.
Maybe I'm slow on the uptake here, but don't
On Tue, 2010-07-27 at 15:23 -0700, Jeff Davis wrote:
On Tue, 2010-07-27 at 17:18 -0400, Robert Haas wrote:
My first concern with that idea was that it may create an inconsistency
between the primary and the standby. The primary could have a bunch of
zero pages that never make it to the
27 matches
Mail list logo
