Prev: ALTER TABLE ... DISABLE TRIGGER vs. AccessExclusiveLock
Next: [HACKERS] Toward a column reorder solution
From: Robert Haas on 29 Jul 2010 12:17
On Thu, Jul 29, 2010 at 11:09 AM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote:
> 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.

It looks like they do. I am able to reproduce the problem even on
8.0, and the patch does fix it.

>> 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.

Done.

--
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: Robert Haas on 29 Jul 2010 10:48
On Wed, Jul 28, 2010 at 5:22 PM, Jeff Davis <pgsql(a)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 page, and uncontroversial is good for things that will be
> back-patched.

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.

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?

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company
First  |  Prev  | 
Pages: 1 2 3 4 5 6
Prev: ALTER TABLE ... DISABLE TRIGGER vs. AccessExclusiveLock
Next: [HACKERS] Toward a column reorder solution