Re: 9.1.2 ? - Mailing list pgsql-hackers

From Daniel Farina
Subject Re: 9.1.2 ?
Date
Msg-id CAAZKuFZ==vRUQY8_rCSZBDs5hYqSSwk_opPHKs31ywKaSNdq-g@mail.gmail.com
Whole thread Raw
In response to Re: 9.1.2 ?  (Greg Smith <greg@2ndQuadrant.com>)
Responses Re: 9.1.2 ?
Re: 9.1.2 ?
List pgsql-hackers
On Wed, Nov 9, 2011 at 2:24 PM, Greg Smith <greg@2ndquadrant.com> wrote:
> I think Daniel has run into this problem more than anyone else, so hearing
> it's fixed for him makes me feel a lot better that it's been resolved.  I'd
> characterize this problem as a medium grade data corruption issue.  It's not
> security issue bad that it needs to be released tomorrow, but a backbranch
> release of at least 9.0/9.1 that includes it would be a big relief for
> people nervous about this.  I'd hate to see that slip forward to where it
> gets sucked into the holiday vortex.

The first time I encountered this I had to reason very carefully for a
while that I just did not suffer some sort of corruption problem or
recovery bug.  After I figured out that normal (non-hot-standby)
recovery worked and what the general mechanism was only then I was
sort-of-assuaged into letting it slide as a workaround.

I think a novice user would be scared half to death: I know I was the
first time.  That's not a great impression for the project to leave
for what is not, at its root, a vast defect, and the fact it's
occurring for people when they use rsync rather than my very sensitive
backup routines is indication that it's not very corner-ey.

So that's my take on it.  It's not a "tomorrow" severity release
(we've been living with the workaround for months, even though it is
blocking some things), but I would really appreciate an expedited
release to enable unattended hot-standby operation and to avoid
scaring those who encounter this.

--
fdr


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: const correctness
Next
From: Steve Singer
Date:
Subject: pg_dump 9.1.1 hanging (collectSecLabels gets 0 labels)