Обсуждение: Re: [PERFORM] Large (almost 50%!) performance drop after upgrading to 8.4.4?
Alvaro Herrera wrote: > Excerpts from Tom Lane's message of jue jun 10 11:46:25 -0400 2010: > > > Yes, the folks at commandprompt need to be told about this. Loudly. > > It's a serious packaging error. > > Just notified Lacey, the packager (not so loudly, though); she's working > on new packages, and apologizes for the inconvenience. [ Thread moved to hackers. 8.4.4 RPMs were built with debug flags. ] Uh, where are we on this? Has it been completed? How are people informed about this? Do we need to post to the announce email list? Does Yum just update them? How did this mistake happen? How many days did it take to detect the problem? Why has no news been posted here? https://public.commandprompt.com/projects/pgcore/news -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + None of us is going to be here forever. +
Re: Re: [PERFORM] Large (almost 50%!) performance drop after upgrading to 8.4.4?
От
Bruce Momjian
Дата:
Bruce Momjian wrote: > Alvaro Herrera wrote: > > Excerpts from Tom Lane's message of jue jun 10 11:46:25 -0400 2010: > > > > > Yes, the folks at commandprompt need to be told about this. Loudly. > > > It's a serious packaging error. > > > > Just notified Lacey, the packager (not so loudly, though); she's working > > on new packages, and apologizes for the inconvenience. > > [ Thread moved to hackers. 8.4.4 RPMs were built with debug flags. ] > > Uh, where are we on this? Has it been completed? How are people > informed about this? Do we need to post to the announce email list? > Does Yum just update them? How did this mistake happen? How many days > did it take to detect the problem? > > Why has no news been posted here? > > https://public.commandprompt.com/projects/pgcore/news Why have I received no reply to this email? Do people think this is not a serious issue? I know it is a weekend but the problem was identified on Thursday, meaning there was a full workday for someone from CommandPrompt to reply to the issue and report a status: http://archives.postgresql.org/pgsql-performance/2010-06/msg00165.php -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + None of us is going to be here forever. +
Bruce Momjian wrote: > Bruce Momjian wrote: > > Alvaro Herrera wrote: > > > Excerpts from Tom Lane's message of jue jun 10 11:46:25 -0400 2010: > > > > > > > Yes, the folks at commandprompt need to be told about this. Loudly. > > > > It's a serious packaging error. > > > > > > Just notified Lacey, the packager (not so loudly, though); she's working > > > on new packages, and apologizes for the inconvenience. > > > > [ Thread moved to hackers. 8.4.4 RPMs were built with debug flags. ] > > > > Uh, where are we on this? Has it been completed? How are people > > informed about this? Do we need to post to the announce email list? > > Does Yum just update them? How did this mistake happen? How many days > > did it take to detect the problem? > > > > Why has no news been posted here? > > > > https://public.commandprompt.com/projects/pgcore/news > > Why have I received no reply to this email? Do people think this is not > a serious issue? I know it is a weekend but the problem was identified > on Thursday, meaning there was a full workday for someone from > CommandPrompt to reply to the issue and report a status: > > http://archives.postgresql.org/pgsql-performance/2010-06/msg00165.php [ Updated subject line.] I am on IM with Joshua Drake right now and am working to get answers to the questions above. He or I will report in the next few hours. FYI, only Command Prompt-produced RPMs are affected. Devrim's RPMs are not: http://yum.postgresqlrpms.org/ -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + None of us is going to be here forever. +
Bruce Momjian wrote: > Bruce Momjian wrote: > > Bruce Momjian wrote: > > > Alvaro Herrera wrote: > > > > Excerpts from Tom Lane's message of jue jun 10 11:46:25 -0400 2010: > > > > > > > > > Yes, the folks at commandprompt need to be told about this. Loudly. > > > > > It's a serious packaging error. > > > > > > > > Just notified Lacey, the packager (not so loudly, though); she's working > > > > on new packages, and apologizes for the inconvenience. > > > > > > [ Thread moved to hackers. 8.4.4 RPMs were built with debug flags. ] > > > > > > Uh, where are we on this? Has it been completed? How are people > > > informed about this? Do we need to post to the announce email list? > > > Does Yum just update them? How did this mistake happen? How many days > > > did it take to detect the problem? > > > > > > Why has no news been posted here? > > > > > > https://public.commandprompt.com/projects/pgcore/news > > > > Why have I received no reply to this email? Do people think this is not > > a serious issue? I know it is a weekend but the problem was identified > > on Thursday, meaning there was a full workday for someone from > > CommandPrompt to reply to the issue and report a status: > > > > http://archives.postgresql.org/pgsql-performance/2010-06/msg00165.php > > [ Updated subject line.] > > I am on IM with Joshua Drake right now and am working to get answers to > the questions above. He or I will report in the next few hours. > > FYI, only Command Prompt-produced RPMs are affected. Devrim's RPMs are > not: > > http://yum.postgresqlrpms.org/ I have still seen no public report about this, 12 hours after talking to Josh Drake on IM about it. :-( -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + None of us is going to be here forever. +
Re: Re: [PERFORM] Large (almost 50%!) performance drop after upgrading to 8.4.4?
От
Alvaro Herrera
Дата:
Excerpts from Bruce Momjian's message of dom jun 13 10:00:16 -0400 2010: > Why have I received no reply to this email? Do people think this is not > a serious issue? I know it is a weekend but the problem was identified > on Thursday, meaning there was a full workday for someone from > CommandPrompt to reply to the issue and report a status: > > http://archives.postgresql.org/pgsql-performance/2010-06/msg00165.php The packager did reply to the original inquiry *on the same day*, but the moderator has not approved that email yet, it seems. I do have the reply on my mbox, with CC: pgsql-performance. -- Álvaro Herrera <alvherre@commandprompt.com> The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Bruce Momjian wrote: > Bruce Momjian wrote: >> Bruce Momjian wrote: >>> Bruce Momjian wrote: >>>> Alvaro Herrera wrote: >>>>> Excerpts from Tom Lane's message of jue jun 10 11:46:25 -0400 2010: >>>>> >>>>>> Yes, the folks at commandprompt need to be told about this. Loudly. >>>>>> It's a serious packaging error. >>>>> Just notified Lacey, the packager (not so loudly, though); she's working >>>>> on new packages, and apologizes for the inconvenience. >>>> [ Thread moved to hackers. 8.4.4 RPMs were built with debug flags. ] >>>> >>>> Uh, where arIf there are further questions, or needs, please let me know, and I will try to get them addressed as soonas I can.e we on this? Has it been completed? How are people >>>> informed about this? Do we need to post to the announce email list? >>>> Does Yum just update them? How did this mistake happen? How many days >>>> did it take to detect the problem? >>>> >>>> Why has no news been posted here? >>>> >>>> https://public.commandprompt.com/projects/pgcore/news >>> Why have I received no reply to this email? Do people think this is not >>> a serious issue? I know it is a weekend but the problem was identified >>> on Thursday, meaning there was a full workday for someone from >>> CommandPrompt to reply to the issue and report a status: >>> >>> http://archives.postgresql.org/pgsql-performance/2010-06/msg00165.php >> [ Updated subject line.] >> >> I am on IM with Joshua Drake right now and am working to get answers to >> the questions above. He or I will report in the next few hours. >> >> FYI, only Command Prompt-produced RPMs are affected. Devrim's RPMs are >> not: >> >> http://yum.postgresqlrpms.org/ > > I have still seen no public report about this, 12 hours after talking to > Josh Drake on IM about it. :-( > Hello Everyone, I tried to send something out Thursday about this to pgsql-performance, and I tried to send something out last night about this to pgsql-announce. Neither seem to have gotten through, or approved. =( =( =( Thursday to the Performance List: Hello Everyone, New packages for 8.4.4 on CentOS 5.5 and RHEL 5.5 (all arches), have been built, and are available in the PGDG repo. http://yum.pgsqlrpms.org/8.4/redhat/rhel-5-i386/ http://yum.pgsqlrpms.org/8.4/redhat/rhel-5-x86_64/ Output from pg_config --configure --version is below. x86_64: '--build=x86_64-redhat-linux-gnu' '--host=x86_64-redhat-linux-gnu' '--target=x86_64-redhat-linux-gnu' '--program-prefix=' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib64' '--libexecdir=/usr/libexec' '--localstatedir=/var' '--sharedstatedir=/usr/com' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--disable-rpath' '--with-perl' '--with-python' '--with-tcl' '--with-tclconfig=/usr/lib64' '--with-openssl' '--with-pam' '--with-krb5' '--with-gssapi' '--with-includes=/usr/include' '--with-libraries=/usr/lib64' '--enable-nls' '--enable-thread-safety' '--with-libxml' '--with-libxslt' '--with-ldap' '--with-system-tzdata=/usr/share/zoneinfo' '--sysconfdir=/etc/sysconfig/pgsql' '--datadir=/usr/share/pgsql' '--with-docdir=/usr/share/doc' 'build_alias=x86_64-redhat-linux-gnu' 'host_alias=x86_64-redhat-linux-gnu' 'target_alias=x86_64-redhat-linux-gnu' 'CFLAGS=-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -I/usr/include/et' 'CPPFLAGS= -I/usr/include/et' PostgreSQL 8.4.4 i386: '--build=i686-redhat-linux-gnu' '--host=i686-redhat-linux-gnu' '--target=i386-redhat-linux-gnu' '--program-prefix=' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib' '--libexecdir=/usr/libexec' '--localstatedir=/var' '--sharedstatedir=/usr/com' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--disable-rpath' '--with-perl' '--with-python' '--with-tcl' '--with-tclconfig=/usr/lib' '--with-openssl' '--with-pam' '--with-krb5' '--with-gssapi' '--with-includes=/usr/include' '--with-libraries=/usr/lib' '--enable-nls' '--enable-thread-safety' '--with-libxml' '--with-libxslt' '--with-ldap' '--with-system-tzdata=/usr/share/zoneinfo' '--sysconfdir=/etc/sysconfig/pgsql' '--datadir=/usr/share/pgsql' '--with-docdir=/usr/share/doc' 'build_alias=i686-redhat-linux-gnu' 'host_alias=i686-redhat-linux-gnu' 'target_alias=i386-redhat-linux-gnu' 'CFLAGS=-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic -fasynchronous-unwind-tables -I/usr/include/et' 'CPPFLAGS= -I/usr/include/et' PostgreSQL 8.4.4 Again, I extend deep apologies for the inconvenience. If there is anything further we can help with, please let us know. Regards, Lacey And last night, for a public announcement: Dear PostgreSQL RPMS users, There was a mistake with the 8.4.4 packages resulting in --enable-debug and --enable-cassert being enabled in the packages for CentOS 5.5 x86_64 and i386. This has been corrected in the 8.4.4-2PGDG packages, which are in the PostgreSQL RPMS repository. Please update to these corrected packages as soon as possible. We apologize for any inconvenience. Regards, Lacey I had this fixed and out in the repo about an hour after I was made aware of it (Alvaro let me know at ~9:30AM PDT ( Thank you *so* much, Alvaro! =) ), and I had things out at ~10:45AM PDT, and tried to reply shortly thereafter. =( ), and tried to let people know as best I could. I know there are a great deal of concerns regarding this, and I am greatly sorry for any trouble that was caused, and will add tests to the build process to ensure that this does not happen again. =( Given the concern, I thought I'd try posting a reply here, to this email, to soothe fears, and to plead for some moderator help, since both of my emails are most likely stuck in moderation. =( =( Again, I'm sorry for the issues I caused, and I will endeavor to make the turnaround and notification time quicker in the future. =( If there are further questions, or needs, please let me know, and I will try to get them addressed as soon as I can. Apologies, Lacey -- Lacey Powers The PostgreSQL Company - Command Prompt, Inc. 1.503.667.4564 ext 104 PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Lacey Powers wrote: > I tried to send something out Thursday about this to pgsql-performance, > and I tried to send something out last night about this to > pgsql-announce. Neither seem to have gotten through, or approved. =( =( =( Yes, I suspected that might have happened. > Thursday to the Performance List: > > Hello Everyone, > > New packages for 8.4.4 on CentOS 5.5 and RHEL 5.5 (all arches), have > been built, and are available in the PGDG repo. > > http://yum.pgsqlrpms.org/8.4/redhat/rhel-5-i386/ > http://yum.pgsqlrpms.org/8.4/redhat/rhel-5-x86_64/ ... > Again, I extend deep apologies for the inconvenience. > > If there is anything further we can help with, please let us know. Do any of the other minor releases made at the same time have this problem, or just 8.4.4? > And last night, for a public announcement: > > > Dear PostgreSQL RPMS users, > > There was a mistake with the 8.4.4 packages resulting in --enable-debug > and --enable-cassert being enabled in the packages for CentOS 5.5 x86_64 > and i386. > > This has been corrected in the 8.4.4-2PGDG packages, which are in the > PostgreSQL RPMS repository. > > Please update to these corrected packages as soon as possible. > > We apologize for any inconvenience. OK, do the Yum folks get these updates automatically? > I had this fixed and out in the repo about an hour after I was made > aware of it (Alvaro let me know at ~9:30AM PDT ( Thank you *so* much, > Alvaro! =) ), and I had things out at ~10:45AM PDT, and tried to reply > shortly thereafter. =( ), and tried to let people know as best I could. > > I know there are a great deal of concerns regarding this, and I am > greatly sorry for any trouble that was caused, and will add tests to the > build process to ensure that this does not happen again. =( > > Given the concern, I thought I'd try posting a reply here, to this > email, to soothe fears, and to plead for some moderator help, since both > of my emails are most likely stuck in moderation. =( =( > > Again, I'm sorry for the issues I caused, and I will endeavor to make > the turnaround and notification time quicker in the future. =( > > If there are further questions, or needs, please let me know, and I will > try to get them addressed as soon as I can. OK, how do we properly get rid of all those buggy 8.4.4 installs? Seems a posting to announce is not enough, and we need to show users how to tell if they are running a de-buggy version. Does the fixed 8.4.4 install have a different visible version number, or do they have to use SHOW debug_assertions? -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + None of us is going to be here forever. +
Bruce Momjian <bruce@momjian.us> writes:
> OK, how do we properly get rid of all those buggy 8.4.4 installs? Seems
> a posting to announce is not enough, and we need to show users how to
> tell if they are running a de-buggy version.
The original thread already covered that in sufficient detail: check
debug_assertions.
regards, tom lane
Tom Lane wrote: > Bruce Momjian <bruce@momjian.us> writes: > > OK, how do we properly get rid of all those buggy 8.4.4 installs? Seems > > a posting to announce is not enough, and we need to show users how to > > tell if they are running a de-buggy version. > > The original thread already covered that in sufficient detail: check > debug_assertions. But this was not communicated in the announce email, which was part of my point. We need to tell people how to get the fix, and how to audit their systems to know they have all been upgrade. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + None of us is going to be here forever. +
Bruce Momjian wrote: > Lacey Powers wrote: >> I tried to send something out Thursday about this to pgsql-performance, >> and I tried to send something out last night about this to >> pgsql-announce. Neither seem to have gotten through, or approved. =( =( =( > > Yes, I suspected that might have happened. > >> Thursday to the Performance List: >> >> Hello Everyone, >> >> New packages for 8.4.4 on CentOS 5.5 and RHEL 5.5 (all arches), have >> been built, and are available in the PGDG repo. >> >> http://yum.pgsqlrpms.org/8.4/redhat/rhel-5-i386/ >> http://yum.pgsqlrpms.org/8.4/redhat/rhel-5-x86_64/ > ... >> Again, I extend deep apologies for the inconvenience. >> >> If there is anything further we can help with, please let us know. > > Do any of the other minor releases made at the same time have this > problem, or just 8.4.4? The only ones affected were 8.4.4 for CentOS 5 x86_64 and i386. 8.3 '--build=x86_64-redhat-linux-gnu' '--host=x86_64-redhat-linux-gnu' '--target=x86_64-redhat-linux-gnu' '--program-prefix=' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib64' '--libexecdir=/usr/libexec' '--localstatedir=/var' '--sharedstatedir=/usr/com' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--disable-rpath' '--with-perl' '--with-python' '--with-tcl' '--with-tclconfig=/usr/lib64' '--with-openssl' '--with-pam' '--with-krb5' '--with-gssapi' '--with-includes=/usr/include' '--with-libraries=/usr/lib64' '--enable-nls' '--enable-thread-safety' '--with-ossp-uuid' '--with-libxml' '--with-libxslt' '--with-ldap' '--with-system-tzdata=/usr/share/zoneinfo' '--sysconfdir=/etc/sysconfig/pgsql' '--datadir=/usr/share/pgsql' '--with-docdir=/usr/share/doc' 'CFLAGS=-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -I/usr/include/et' 'CPPFLAGS= -I/usr/include/et' 'build_alias=x86_64-redhat-linux-gnu' 'host_alias=x86_64-redhat-linux-gnu' 'target_alias=x86_64-redhat-linux-gnu' PostgreSQL 8.3.11 8.2 '--build=x86_64-redhat-linux-gnu' '--host=x86_64-redhat-linux-gnu' '--target=x86_64-redhat-linux-gnu' '--program-prefix=' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib64' '--libexecdir=/usr/libexec' '--localstatedir=/var' '--sharedstatedir=/usr/com' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--disable-rpath' '--with-perl' '--with-python' '--with-tcl' '--with-tclconfig=/usr/lib64' '--with-openssl' '--with-pam' '--with-krb5' '--with-includes=/usr/include' '--with-libraries=/usr/lib64' '--enable-nls' '--enable-thread-safety' '--sysconfdir=/etc/sysconfig/pgsql' '--datadir=/usr/share/pgsql' '--with-docdir=/usr/share/doc' 'CFLAGS=-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -I/usr/include/et' 'CPPFLAGS= -I/usr/include/et' 'build_alias=x86_64-redhat-linux-gnu' 'host_alias=x86_64-redhat-linux-gnu' 'target_alias=x86_64-redhat-linux-gnu' PostgreSQL 8.2.17 8.1 '--build=x86_64-redhat-linux-gnu' '--host=x86_64-redhat-linux-gnu' '--target=x86_64-redhat-linux-gnu' '--program-prefix=' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib64' '--libexecdir=/usr/libexec' '--localstatedir=/var' '--sharedstatedir=/usr/com' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--disable-rpath' '--with-perl' '--with-tcl' '--with-tclconfig=/usr/lib64' '--with-python' '--with-openssl' '--with-pam' '--with-krb5' '--with-includes=/usr/include' '--with-libraries=/usr/lib64' '--enable-nls' '--enable-thread-safety' '--sysconfdir=/etc/sysconfig/pgsql' '--datadir=//usr/share/pgsql' '--with-docdir=/usr/share/doc' 'CFLAGS=-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -I/usr/include/et' 'CPPFLAGS= -I/usr/include/et' 'build_alias=x86_64-redhat-linux-gnu' 'host_alias=x86_64-redhat-linux-gnu' 'target_alias=x86_64-redhat-linux-gnu' PostgreSQL 8.1.21 8.0 '--build=x86_64-redhat-linux-gnu' '--host=x86_64-redhat-linux-gnu' '--target=x86_64-redhat-linux-gnu' '--program-prefix=' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib64' '--libexecdir=/usr/libexec' '--localstatedir=/var' '--sharedstatedir=/usr/com' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--disable-rpath' '--with-perl' '--with-tcl' '--with-tclconfig=/usr/lib64' '--with-openssl' '--with-pam' '--with-krb5' '--with-includes=/usr/include' '--with-libraries=/usr/lib' '--enable-nls' '--sysconfdir=/etc/sysconfig/pgsql' '--datadir=/usr/share/pgsql' '--with-docdir=/usr/share/doc' 'CFLAGS=-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -I/usr/include/et' 'CPPFLAGS= -I/usr/include/et' 'build_alias=x86_64-redhat-linux-gnu' 'host_alias=x86_64-redhat-linux-gnu' 'target_alias=x86_64-redhat-linux-gnu' PostgreSQL 8.0.25 7.4 '--build=x86_64-redhat-linux-gnu' '--host=x86_64-redhat-linux-gnu' '--target=x86_64-redhat-linux-gnu' '--program-prefix=' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib64' '--libexecdir=/usr/libexec' '--localstatedir=/var' '--sharedstatedir=/usr/com' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--disable-rpath' '--with-perl' '--with-tcl' '--with-tclconfig=/usr/lib64' '--without-tk' '--with-python' '--with-openssl' '--with-pam' '--with-krb5=/usr' '--with-includes=/usr/include/et' '--enable-nls' '--enable-thread-safety' '--sysconfdir=/etc/sysconfig/pgsql' '--datadir=/usr/share/pgsql' '--with-docdir=/usr/share/doc' 'CFLAGS=-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -I/usr/include/et' 'CPPFLAGS= -I/usr/include/et' 'build_alias=x86_64-redhat-linux-gnu' 'host_alias=x86_64-redhat-linux-gnu' 'target_alias=x86_64-redhat-linux-gnu' PostgreSQL 7.4.29 And verified to be shut off in all of the spec files in the current svn revision, and changed only in the 8.4.4 spec file according to the svn history: find . -type f -name 'postgresql-[0-9].[0-9].spec' -exec grep -i '%define beta' '{}' \; -print %define beta 0 ./7.4/postgresql/EL-5/postgresql-7.4.spec %define beta 0 ./7.4/postgresql/EL-4/postgresql-7.4.spec %define beta 0 ./8.0/postgresql/F-12/postgresql-8.0.spec %define beta 0 ./8.0/postgresql/F-11/postgresql-8.0.spec %define beta 0 ./8.0/postgresql/EL-5/postgresql-8.0.spec %define beta 0 ./8.0/postgresql/EL-4/postgresql-8.0.spec %define beta 0 ./8.1/postgresql/F-12/postgresql-8.1.spec %define beta 0 ./8.1/postgresql/F-11/postgresql-8.1.spec %define beta 0 ./8.1/postgresql/EL-5/postgresql-8.1.spec %define beta 0 ./8.1/postgresql/EL-4/postgresql-8.1.spec %define beta 0 ./8.3/postgresql-intdatetime/F-12/postgresql-8.3.spec %define beta 0 ./8.3/postgresql-intdatetime/F-11/postgresql-8.3.spec %define beta 0 ./8.3/postgresql-intdatetime/EL-5/postgresql-8.3.spec %define beta 0 ./8.3/postgresql-intdatetime/EL-4/postgresql-8.3.spec %define beta 0 ./8.3/postgresql/F-12/postgresql-8.3.spec %define beta 0 ./8.3/postgresql/F-11/postgresql-8.3.spec %define beta 0 ./8.3/postgresql/EL-5/postgresql-8.3.spec %define beta 0 ./8.3/postgresql/EL-4/postgresql-8.3.spec %define beta 0 ./8.4/postgresql/F-12/postgresql-8.4.spec %define beta 0 ./8.4/postgresql/F-11/postgresql-8.4.spec %define beta 0 ./8.4/postgresql/EL-5/postgresql-8.4.spec %define beta 0 ./8.4/postgresql/EL-4/postgresql-8.4.spec %define beta 0 ./8.4/postgresql-mv/F-12/postgresql-8.4.spec %define beta 0 ./8.4/postgresql-mv/F-11/postgresql-8.4.spec %define beta 0 ./8.4/postgresql-mv/EL-5/postgresql-8.4.spec %define beta 0 ./8.4/postgresql-mv/EL-4/postgresql-8.4.spec %define beta 0 ./9.0/postgresql/F-12/postgresql-9.0.spec %define beta 0 ./9.0/postgresql/F-11/postgresql-9.0.spec %define beta 0 ./9.0/postgresql/EL-5/postgresql-9.0.spec %define beta 0 ./9.0/postgresql/EL-4/postgresql-9.0.spec %define beta 0 ./8.2/postgresql/F-12/postgresql-8.2.spec %define beta 0 ./8.2/postgresql/F-11/postgresql-8.2.spec %define beta 0 ./8.2/postgresql/EL-5/postgresql-8.2.spec %define beta 0 ./8.2/postgresql/EL-4/postgresql-8.2.spec > >> And last night, for a public announcement: >> >> >> Dear PostgreSQL RPMS users, >> >> There was a mistake with the 8.4.4 packages resulting in --enable-debug >> and --enable-cassert being enabled in the packages for CentOS 5.5 x86_64 >> and i386. >> >> This has been corrected in the 8.4.4-2PGDG packages, which are in the >> PostgreSQL RPMS repository. >> >> Please update to these corrected packages as soon as possible. >> >> We apologize for any inconvenience. > > OK, do the Yum folks get these updates automatically? Yup. I updated the package version to 8.4.4-2PGDG, so this should update in yum automatically, if you do a yum update. > >> I had this fixed and out in the repo about an hour after I was made >> aware of it (Alvaro letwget -c http://yum.pgsqlrpms.org/7.4/redhat/rhel-5-x86_64/postgresql-7.4.29-1PGDG.el5.x86_64.rpm >> wget -c http://yum.pgsqlrpms.org/7.4/redhat/rhel-5-x86_64/postgresql-contrib-7.4.29-1PGDG.el5.x86_64.rpm >> wget -c http://yum.pgsqlrpms.org/7.4/redhat/rhel-5-x86_64/postgresql-debuginfo-7.4.29-1PGDG.el5.x86_64.rpm >> wget -c http://yum.pgsqlrpms.org/7.4/redhat/rhel-5-x86_64/postgresql-devel-7.4.29-1PGDG.el5.x86_64.rpm >> wget -c http://yum.pgsqlrpms.org/7.4/redhat/rhel-5-x86_64/postgresql-docs-7.4.29-1PGDG.el5.x86_64.rpm >> wget -c http://yum.pgsqlrpms.org/7.4/redhat/rhel-5-x86_64/postgresql-libs-7.4.29-1PGDG.el5.x86_64.rpm >> wget -c http://yum.pgsqlrpms.org/7.4/redhat/rhel-5-x86_64/postgresql-pl-7.4.29-1PGDG.el5.x86_64.rpm >> wget -c http://yum.pgsqlrpms.org/7.4/redhat/rhel-5-x86_64/postgresql-server-7.4.29-1PGDG.el5.x86_64.rpm >> wget -c http://yum.pgsqlrpms.org/7.4/redhat/rhel-5-x86_64/postgresql-test-7.4.29-1PGDG.el5.x86_64.rpm me know at ~9:30AMPDT ( Thank you *so* much, >> Alvaro! =) ), and I had things out at ~10:45AM PDT, and tried to reply >> shortly thereafter. =( ), and tried to let people know as best I could. >> >> I know there are a great deal of concerns regarding this, and I am >> greatly sorry for any trouble that was caused, and will add tests to the >> build process to ensure that this does not happen again. =( >> >> Given the concern, I thought I'd try posting a reply here, to this >> email, to soothe fears, and to plead for some moderator help, since both >> of my emails are most likely stuck in moderation. =( =( >> >> Again, I'm sorry for the issues I caused, and I will endeavor to make >> the turnaround and notification time quicker in the future. =( >> >> If there are further questions, or needs, please let me know, and I will >> try to get them addressed as soon as I can. > > OK, how do we properly get rid of all those buggy 8.4.4 installs? Seems > a posting to announce is not enough, and we need to show users how to > tell if they are running a de-buggy version. Does the fixed 8.4.4 > install have a different visible version number, or do they have to use > SHOW debug_assertions? You can tell from the package name, using: rpm -qa | grep 'postgresql' postgresql-server-8.4.4-1PGDG.el5 -- Debugging Enabled. =( =( =( postgresql-server-8.4.4-2PGDG.el5 -- Debugging Disabled. =) =) =) Or with: pg_config --configure | grep 'debug\|cassert' if you install the -devel package. Or as you said: SHOW debug_assertions I hope that answers your questions. I'll write up another announcement that has the ways you can tell, and urges people who are using yum to update to the next package revision via yum. Thank you, Lacey -- Lacey Powers The PostgreSQL Company - Command Prompt, Inc. 1.503.667.4564 ext 104 PostgreSQL Replication, Consulting, Custom Development, 24x7 support
On 6/14/10 3:39 PM, Lacey Powers wrote:
> Bruce Momjian wrote:
>> Lacey Powers wrote:
>>> I tried to send something out Thursday about this to
>>> pgsql-performance, and I tried to send something out last night about
>>> this to pgsql-announce. Neither seem to have gotten through, or
>>> approved. =( =( =(
Hmmm. I'm the approver for pgsql-performance, but somehow I didn't get
the moderator e-mail for you. Approved now. Sorry.
-- -- Josh Berkus PostgreSQL Experts Inc.
http://www.pgexperts.com
Lacey Powers wrote: >> >> Do any of the other minor releases made at the same time have this >> problem, or just 8.4.4? > > The only ones affected were 8.4.4 for CentOS 5 x86_64 and i386. > > That also covers RHEL5 x86_64/i386, no? I assume you use the same RPMs for both. cheers andrew
Andrew Dunstan wrote: > > > Lacey Powers wrote: >>> >>> Do any of the other minor releases made at the same time have this >>> problem, or just 8.4.4? >> >> The only ones affected were 8.4.4 for CentOS 5 x86_64 and i386. >> >> > > That also covers RHEL5 x86_64/i386, no? I assume you use the same RPMs > for both. > > cheers > > andrew > Yes, it covers RHEL 5 too. =) We do use the same RPM for both. Lacey -- Lacey Powers The PostgreSQL Company - Command Prompt, Inc. 1.503.667.4564 ext 104 PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Josh Berkus wrote: > On 6/14/10 3:39 PM, Lacey Powers wrote: >> Bruce Momjian wrote: >>> Lacey Powers wrote: >>>> I tried to send something out Thursday about this to >>>> pgsql-performance, and I tried to send something out last night about >>>> this to pgsql-announce. Neither seem to have gotten through, or >>>> approved. =( =( =( > > Hmmm. I'm the approver for pgsql-performance, but somehow I didn't get > the moderator e-mail for you. Approved now. Sorry. > No big. =) Thank you very much for approving me! =) Lacey -- Lacey Powers The PostgreSQL Company - Command Prompt, Inc. 1.503.667.4564 ext 104 PostgreSQL Replication, Consulting, Custom Development, 24x7 support