page corruption on 8.3+ that makes it to standby
in [PgSql]
|
Prev: ALTER TABLE ... DISABLE TRIGGER vs. AccessExclusiveLock
Next: [HACKERS] Toward a column reorder solution
From: Jeff Davis on 28 Jul 2010 17:22 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. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Simon Riggs on 29 Jul 2010 04:58 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 uncontroversial is good for things that will be > back-patched. 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. -- Simon Riggs www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Training and Services -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Robert Haas on 29 Jul 2010 09:10 On Thu, Jul 29, 2010 at 4:58 AM, Simon Riggs <simon(a)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 to have a simple guard against corrupting an >> uninitialized page, and uncontroversial is good for things that will be >> back-patched. > > 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 that. As Jeff Davis pointed out, if someone asks to move a table to a different tablespace, changing the contents as we go along seems a bit off-topic. But the bigger problem is you haven't explained how you think we could determine what initialization ought to be performed. There's no index-AM API that says "initialize this page". I suppose we could invent one if there were some benefit, but we couldn't very well back-patch such a thing to 8.0. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Tom Lane on 29 Jul 2010 11:09 Robert Haas <robertmhaas(a)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 applies to > REL8_1_STABLE and REL8_0_STABLE. REL7_4_STABLE doesn't have > tablespaces, so the problem can't manifest there, I think. Looks sane to the eyeball. I'm not sure if the oldest versions have the same page-read-time header sanity checks that we have now, so it may be that there is not a need for this patch all the way back; but it can't hurt anything. > I'm currently compiling and testing all of these. When that's done, > should I go ahead and check this in, or wait until after beta4 wraps? Go ahead and commit, please. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Tom Lane on 29 Jul 2010 10:35
Robert Haas <robertmhaas(a)gmail.com> writes: > On Thu, Jul 29, 2010 at 4:58 AM, Simon Riggs <simon(a)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 that. As Jeff Davis pointed > out, if someone asks to move a table to a different tablespace, > changing the contents as we go along seems a bit off-topic. But the > bigger problem is you haven't explained how you think we could > determine what initialization ought to be performed. There's no > index-AM API that says "initialize this page". I suppose we could > invent one if there were some benefit, but we couldn't very well > back-patch such a thing to 8.0. Yeah. And you really would have to get the AM involved. Even if you were willing to assume that you knew the special-space size for a particular index type, it would not fly to assume that the special space doesn't require initialization to some nonzero content. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |