Thread: 9.1.2 ?
Given the amount of fixes that went into the branch, and importance of them - when can we expect 9.1.2 to be released officially? 9.1.1 was stamped on 22nd of September.
Greg Jaskiewicz <gj@pointblue.com.pl> writes:
> Given the amount of fixes that went into the branch, and importance of them - when can we expect 9.1.2 to be released
officially?
> 9.1.1 was stamped on 22nd of September.
That's barely more than six weeks ago. Usually, in the absence of any
seriously nasty bugs, Postgres update releases are three months or more
apart; more often than that puts undue load on our downstream packagers.
I don't recall that we've fixed anything since September that seemed to
warrant an immediate release.
regards, tom lane
On 11/08/2011 07:34 PM, Tom Lane wrote: > I don't recall that we've fixed anything since September that seemed to > warrant an immediate release. > The backup+pg_clog failure issues fixed last week have been a nasty problem hitting people for a while. Backup corruption is obviously serious. Only reason I think it wasn't a higher priority issue is that it didn't happen every time, and the people impacted were eventually able to work around it. Concern about that problem is why I popped off a message earlier today, about whether the fixes committed have been confirmed outside of Simon's own testing. I was curious how 9.0 fared last year for comparison, here's that data: Version Date Days Weeks 9.0.0 09/20/10 9.0.1 10/04/10 14 2.0 9.0.2 12/16/10 73 10.4 9.0.3 01/31/11 46 6.6 9.0.4 04/18/11 77 11.0 9.0.5 09/26/11 161 23.0 So the average for the first three point releases was around 6 weeks apart. -- Greg Smith 2ndQuadrant US greg@2ndQuadrant.com Baltimore, MD PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.us
Greg Smith <greg@2ndQuadrant.com> writes:
> I was curious how 9.0 fared last year for comparison, here's that data:
> Version Date Days Weeks
> 9.0.0 09/20/10
> 9.0.1 10/04/10 14 2.0
> 9.0.2 12/16/10 73 10.4
> 9.0.3 01/31/11 46 6.6
> 9.0.4 04/18/11 77 11.0
> 9.0.5 09/26/11 161 23.0
> So the average for the first three point releases was around 6 weeks apart.
The 9.0.1 and 9.0.3 releases were both forced by security issues,
so I think that's an unusually low average.
Having said that, if enough people think that those backup issues are
critical-data-loss problems, I won't stand in the way of making a
release now. But like you, I'm not exactly convinced we're done with
those issues.
regards, tom lane
<p>On Nov 9, 2011 3:25 AM, "Tom Lane" <<a href="mailto:tgl@sss.pgh.pa.us">tgl@sss.pgh.pa.us</a>> wrote:<br /> ><br/> > Greg Smith <greg@2ndQuadrant.com> writes:<br /> > > I was curious how 9.0 fared last year forcomparison, here's that data:<br /> ><br /> > > Version Date Days Weeks<br /> > > 9.0.0 09/20/10<br/> > > 9.0.1 10/04/10 14 2.0<br /> > > 9.0.2 12/16/10 73 10.4<br /> > > 9.0.3 01/31/11 46 6.6<br /> > > 9.0.4 04/18/11 77 11.0<br /> > > 9.0.5 09/26/11 161 23.0<br /> ><br /> > > So the average for the first three point releases was around 6 weeks apart.<br /> ><br/> > The 9.0.1 and 9.0.3 releases were both forced by security issues,<br /> > so I think that's an unusuallylow average.<br /> ><br /> > Having said that, if enough people think that those backup issues are<br /> >critical-data-loss problems, I won't stand in the way of making a<br /> > release now. But like you, I'm not exactlyconvinced we're done with<br /> > those issues.<br /> ><p>I definitely think they are important enough to triggera release. But as you say, I think we need confirmation that they actually fix the problem... <p>/Magnus <br />
On 9 Nov 2011, at 05:06, Magnus Hagander wrote:
Would you consider it a blocker for a rollout on production system ?I definitely think they are important enough to trigger a release. But as you say, I think we need confirmation that they actually fix the problem...
> I definitely think they are important enough to trigger a release. But as > you say, I think we need confirmation that they actually fix the problem... Just last night Heroku was offering to help us test replication stuff. I'll take them up on it. Link for the patch and issue in question? -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com
On 11/09/2011 01:12 PM, Greg Jaskiewicz wrote: > Would you consider it a blocker for a rollout on production system ? I wouldn't. Good process for checking your backups should find this problem if it pops up, and it's not that easy to run into. That's why I was saying there are workarounds here, they're just not nice to put people through. -- Greg Smith 2ndQuadrant US greg@2ndQuadrant.com Baltimore, MD PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.us
On Wed, Nov 9, 2011 at 12:58 PM, Daniel Farina <daniel@heroku.com> wrote: > On Tue, Nov 8, 2011 at 9:06 PM, Magnus Hagander <magnus@hagander.net> wrote: >> I definitely think they are important enough to trigger a release. But as >> you say, I think we need confirmation that they actually fix the problem... > > I have confirmed that the clog/subtrans fixes allow us to start up > while in hot standby on otherwise problematic base backups. Also, this is something of a big deal to us; otherwise it happens frequently enough that I cannot claim that I can use hot standby in an unattended, automated way. -- fdr
On Tue, Nov 8, 2011 at 9:06 PM, Magnus Hagander <magnus@hagander.net> wrote: > I definitely think they are important enough to trigger a release. But as > you say, I think we need confirmation that they actually fix the problem... I have confirmed that the clog/subtrans fixes allow us to start up while in hot standby on otherwise problematic base backups. -- fdr
On 11/09/2011 03:58 PM, Daniel Farina wrote: > On Tue, Nov 8, 2011 at 9:06 PM, Magnus Hagander<magnus@hagander.net> wrote: > >> I definitely think they are important enough to trigger a release. But as >> you say, I think we need confirmation that they actually fix the problem... >> > I have confirmed that the clog/subtrans fixes allow us to start up > while in hot standby on otherwise problematic base backups. > 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. -- Greg Smith 2ndQuadrant US greg@2ndQuadrant.com Baltimore, MD PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.us
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
> 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. The earliest we could release an update would the November 21st, the monday before American Thanksgiving. That seems doable to me ... should we ping the packagers about it? -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com
On Nov9, 2011, at 23:53 , Daniel Farina wrote: > 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. Just to emphasize the non-conerish-ness of this problem, it should be mentioned that the HS issue was observed even with backups taken with pg_basebackup, if memory serves correctly. best regards, Florian Pflug
On 11/09/2011 03:56 PM, Josh Berkus wrote: > > >> 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. > > The earliest we could release an update would the November 21st, the > monday before American Thanksgiving. That seems doable to me ... should > we ping the packagers about it? Ehhh.... That week is kind of moot for most of the United States. Shouldn't it be like Tuesday the week after? JD > -- Command Prompt, Inc. - http://www.commandprompt.com/ PostgreSQL Support, Training, Professional Services and Development The PostgreSQL Conference - http://www.postgresqlconference.org/ @cmdpromptinc - @postgresconf - 509-416-6579
> Ehhh.... That week is kind of moot for most of the United States. > Shouldn't it be like Tuesday the week after? Given that we start packaging on Thursday, that would mean waiting an additional 2 weeks. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com
On Wed, Nov 9, 2011 at 9:03 PM, Josh Berkus <josh@agliodbs.com> wrote: >> Ehhh.... That week is kind of moot for most of the United States. >> Shouldn't it be like Tuesday the week after? > > Given that we start packaging on Thursday, that would mean waiting an > additional 2 weeks. Yeah, I don't see what's wrong with the 21st. People may not install the update the minute it comes out, but that's not necessarily a big deal, especially since it's not a security update. The point is that all the packaging will be done *before* people leave to go eat Turkey. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On Wed, 2011-11-09 at 21:12 -0500, Robert Haas wrote: > The point is that all the packaging will be done *before* people leave > to go eat Turkey. Eating me? -- Devrim GÜNDÜZ Principal Systems Engineer @ EnterpriseDB: http://www.enterprisedb.com PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer Community: devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr http://www.gunduz.org Twitter: http://twitter.com/devrimgunduz
2011/11/9 Devrim GÜNDÜZ <devrim@gunduz.org>: > On Wed, 2011-11-09 at 21:12 -0500, Robert Haas wrote: >> The point is that all the packaging will be done *before* people leave >> to go eat Turkey. > > Eating me? :-) No, just your country. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On 11/09/2011 06:15 PM, Robert Haas wrote: > > 2011/11/9 Devrim GÜNDÜZ<devrim@gunduz.org>: >> On Wed, 2011-11-09 at 21:12 -0500, Robert Haas wrote: >>> The point is that all the packaging will be done *before* people leave >>> to go eat Turkey. >> >> Eating me? > > :-) > > No, just your country. I hear it is a little dry. -- Command Prompt, Inc. - http://www.commandprompt.com/ PostgreSQL Support, Training, Professional Services and Development The PostgreSQL Conference - http://www.postgresqlconference.org/ @cmdpromptinc - @postgresconf - 509-416-6579
Robert Haas <robertmhaas@gmail.com> writes:
> On Wed, Nov 9, 2011 at 9:03 PM, Josh Berkus <josh@agliodbs.com> wrote:
>> Given that we start packaging on Thursday, that would mean waiting an
>> additional 2 weeks.
> Yeah, I don't see what's wrong with the 21st.
One advantage of waiting two more weeks is that we could declare it to
be the final 8.2.x release, because we'd be into December.
Also, I concur with JD that releasing Thanksgiving week is a good way
to ensure that nobody in the US notices. First week of December would
be a lot better (and is really about the only slot that's left before
the new year).
regards, tom lane
2011-11-10 03:35 keltezéssel, Joshua D. Drake írta: > > On 11/09/2011 06:15 PM, Robert Haas wrote: >> >> 2011/11/9 Devrim GÜNDÜZ<devrim@gunduz.org>: >>> On Wed, 2011-11-09 at 21:12 -0500, Robert Haas wrote: >>>> The point is that all the packaging will be done *before* people leave >>>> to go eat Turkey. >>> >>> Eating me? >> >> :-) >> >> No, just your country. > > I hear it is a little dry. Especially on the throat, as the Koran forbids wine. :-) But that didn't prohibit turks enjoy wine in Hungary from 1526 to 1686, Hungary was occupied during that time by the turks. It's documented by some historian that their belief was that Allah listened in their heads and in their smartness they figured out that they just had to yell loudly. This way Allah scared off and ran into their legs and he didn't notice them drinking wine. :-D I didn't mean to offend you, Devrim ;-) -- ---------------------------------- Zoltán Böszörményi Cybertec Schönig & Schönig GmbH Gröhrmühlgasse 26 A-2700 Wiener Neustadt, Austria Web: http://www.postgresql-support.de http://www.postgresql.at/
On Wed, Nov 9, 2011 at 6:22 PM, Florian Pflug <fgp@phlo.org> wrote:
On Nov9, 2011, at 23:53 , Daniel Farina wrote:Just to emphasize the non-conerish-ness of this problem, it should be
> 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.
mentioned that the HS issue was observed even with backups taken with
pg_basebackup, if memory serves correctly.
Yes I personally can reliably reproduce both the clog+subtrans problems using pg_basebackup, and can confirm that the "oldestActiveXid_fixed.v2.patch" does resolve both issues.