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 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
no_lsn_tli_on_zero_page.patch
Description: Binary data
no_lsn_tli_on_zero_page-v82.patch
Description: Binary data
no_lsn_tli_on_zero_page-v81.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
