Re: [PERFORM] Large (almost 50%!) performance drop after upgrading to 8.4.4?

Hi,
I was doing some benchmarking while changing configuration options to try to get more performance out of our postgresql servers and noticed that when running pgbench against 8.4.3 vs 8.4.4 on identical hardware and configuration there is a large difference in performance. I know tuning is a very deep topic and benchmarking is hardly an accurate indication of real world performance but I was still surprised by these results and wanted to know what I am doing wrong.

OS is CentOS 5.5 and the postgresql packages are from the pgdg repo.

Hardware specs are:
2x Quad core Xeons 2.4Ghz
16GB RAM
2x RAID1 7.2k RPM disks (slow I know, but we are upgrading them soon..)

Relevant Postgresql Configuration:
max_connections = 1000
shared_buffers = 4096MB
temp_buffers = 8MB
max_prepared_transactions = 1000
work_mem = 8MB
maintenance_work_mem = 512MB
wal_buffers = 8MB
checkpoint_segments = 192
checkpoint_timeout = 30min
effective_cache_size = 12288MB

Results for the 8.4.3 (8.4.3-2PGDG.el5) host:
[root(at)some-host ~]# pgbench -h dbs3 -U postgres -i -s 100 pgbench1 > /dev/null 2>&1 && pgbench -h dbs3 -U postgres -c 100 -t 100000 pgbench1
starting vacuum...end.
transaction type: TPC-B (sort of)
scaling factor: 100
query mode: simple
number of clients: 100
number of transactions per client: 100000
number of transactions actually processed: 10000000/10000000
tps = 5139.554921 (including connections establishing)
tps = 5140.325850 (excluding connections establishing)
opreport:
CPU: Intel Core/i7, speed 2394.07 MHz (estimated)
Counted CPU_CLK_UNHALTED events (Clock cycles when not halted) with a unit mask of 0x00 (No unit mask) count 100000
CPU_CLK_UNHALT...|
samples| %|
------------------
37705832 61.3683 postgres
18472598 30.0652 no-vmlinux
4982274 8.1089 libc-2.5.so
138517 0.2254 oprofiled
134628 0.2191 libm-2.5.so
1465 0.0024 libc-2.5.so
1454 0.0024 libperl.so
793 0.0013 libdcsupt.so.5.9.2
444 7.2e-04 dsm_sa_datamgrd
CPU_CLK_UNHALT...|
samples| %|
------------------
401 90.3153 dsm_sa_datamgrd
43 9.6847 anon (tgid:8013 range:0xffffe000-0xfffff000)
410 6.7e-04 libxml2.so.2.6.26
356 5.8e-04 ld-2.5.so
332 5.4e-04 libnetsnmp.so.10.0.3
327 5.3e-04 dsm_sa_snmpd
CPU_CLK_UNHALT...|
samples| %|
------------------
255 77.9817 dsm_sa_snmpd
72 22.0183 anon (tgid:8146 range:0xffffe000-0xfffff000)
304 4.9e-04 libcrypto.so.0.9.8e
290 4.7e-04 libpthread-2.5.so
199 3.2e-04 libdcsmil.so.5.9.2
139 2.3e-04 modclusterd
<snip>

Results for the 8.4.4 (8.4.4-1PGDG.el5) host:
[root@ some-host ~]# pgbench -h dbs4 -U postgres -i -s 100 pgbench1 > /dev/null 2>&1 && pgbench -h dbs4 -U postgres -c 100 -t 100000 pgbench1
starting vacuum...end.
transaction type: TPC-B (sort of)
scaling factor: 100
query mode: simple
number of clients: 100
number of transactions per client: 100000
number of transactions actually processed: 10000000/10000000
tps = 2765.643549 (including connections establishing)
tps = 2765.931203 (excluding connections establishing)
opreport:
CPU: Intel Core/i7, speed 2394.07 MHz (estimated)
Counted CPU_CLK_UNHALTED events (Clock cycles when not halted) with a unit mask of 0x00 (No unit mask) count 100000
CPU_CLK_UNHALT...|
samples| %|
------------------
312481395 84.5038 postgres
41861164 11.3204 no-vmlinux
14290652 3.8646 libc-2.5.so
812148 0.2196 oprofiled
305909 0.0827 libm-2.5.so
7647 0.0021 libc-2.5.so
3809 0.0010 libdcsupt.so.5.9.2
3077 8.3e-04 libperl.so
2302 6.2e-04 dsm_sa_datamgrd
CPU_CLK_UNHALT...|
samples| %|
------------------
2113 91.7897 dsm_sa_datamgrd
189 8.2103 anon (tgid:8075 range:0xffffe000-0xfffff000)
2175 5.9e-04 libxml2.so.2.6.26
1455 3.9e-04 dsm_sa_snmpd
CPU_CLK_UNHALT...|
samples| %|
------------------
1226 84.2612 dsm_sa_snmpd
229 15.7388 anon (tgid:8208 range:0xffffe000-0xfffff000)
1227 3.3e-04 libdchipm.so.5.9.2
1192 3.2e-04 libpthread-2.5.so
804 2.2e-04 libnetsnmp.so.10.0.3
745 2.0e-04 modclusterd
<snip>

Any input? I can reproduce these numbers consistently. If you need more information then just let me know. By the way, I am a new postgresql user so my experience is limited.
Cheers,
Max

Can you give the config params for those :

fsync =
synchronous_commit =
wal_sync_method =

Also, some "vmstat 1" output during the runs would be interesting.

On Wed, Jun 9, 2010 at 6:56 AM, Max Williams <Max(dot)Williams(at)mflow(dot)com> wrote:
> Any input? I can reproduce these numbers consistently. If you need more
> information then just let me know. By the way, I am a new postgresql user so
> my experience is limited.

Maybe different compile options? If we'd really slowed things down by
50% between 8.4.3 and 8.4.4, there'd be an awful lot of people
screaming about it...

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company

Well the packages are from the pgdg repo which I would have thought are pretty common?
https://public.commandprompt.com/projects/pgcore/wiki

-----Original Message-----
From: Robert Haas [mailto:robertmhaas(at)gmail(dot)com]
Sent: 10 June 2010 02:52
To: Max Williams
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: [PERFORM] Large (almost 50%!) performance drop after upgrading to 8.4.4?

On Wed, Jun 9, 2010 at 6:56 AM, Max Williams <Max(dot)Williams(at)mflow(dot)com> wrote:
> Any input? I can reproduce these numbers consistently. If you need more
> information then just let me know. By the way, I am a new postgresql user so
> my experience is limited.

Maybe different compile options? If we'd really slowed things down by
50% between 8.4.3 and 8.4.4, there'd be an awful lot of people
screaming about it...

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company

On Wed, 2010-06-09 at 21:51 -0400, Robert Haas wrote:
> On Wed, Jun 9, 2010 at 6:56 AM, Max Williams <Max(dot)Williams(at)mflow(dot)com>
> wrote:
> > Any input? I can reproduce these numbers consistently. If you need
> more
> > information then just let me know. By the way, I am a new postgresql
> user so
> > my experience is limited.
>
> Maybe different compile options? If we'd really slowed things down by
> 50% between 8.4.3 and 8.4.4, there'd be an awful lot of people
> screaming about it...

Given that there are 2 recent reports on the same issue, I wonder if the
new packages were built with debugging options or not.

--
Devrim GÜNDÜZ
PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer
PostgreSQL RPM Repository: http://yum.pgrpms.org
Community: devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr
http://www.gunduz.org Twitter: http://twitter.com/devrimgunduz

How do I tell if it was built with debugging options?

-----Original Message-----
From: Devrim GÜNDÜZ [mailto:devrim(at)gunduz(dot)org]
Sent: 10 June 2010 09:30
To: Robert Haas
Cc: Max Williams; pgsql-performance(at)postgresql(dot)org
Subject: Re: [PERFORM] Large (almost 50%!) performance drop after upgrading to 8.4.4?

On Wed, 2010-06-09 at 21:51 -0400, Robert Haas wrote:
> On Wed, Jun 9, 2010 at 6:56 AM, Max Williams <Max(dot)Williams(at)mflow(dot)com>
> wrote:
> > Any input? I can reproduce these numbers consistently. If you need
> more
> > information then just let me know. By the way, I am a new postgresql
> user so
> > my experience is limited.
>
> Maybe different compile options? If we'd really slowed things down by
> 50% between 8.4.3 and 8.4.4, there'd be an awful lot of people
> screaming about it...

Given that there are 2 recent reports on the same issue, I wonder if the new packages were built with debugging options or not.

--
Devrim GÜNDÜZ
PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer PostgreSQL RPM Repository: http://yum.pgrpms.org
Community: devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr http://www.gunduz.org Twitter: http://twitter.com/devrimgunduz

Max Williams <Max(dot)Williams(at)mflow(dot)com> writes:
> How do I tell if it was built with debugging options?

Run pg_config --configure and see if --enable-cassert is mentioned.

regards, tom lane

I'm afraid pg_config is not part of the pgdg packages.

-----Original Message-----
From: Tom Lane [mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us]
Sent: 10 June 2010 15:11
To: Max Williams
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: [PERFORM] Large (almost 50%!) performance drop after upgrading to 8.4.4?

Max Williams <Max(dot)Williams(at)mflow(dot)com> writes:
> How do I tell if it was built with debugging options?

Run pg_config --configure and see if --enable-cassert is mentioned.

regards, tom lane

Max Williams <Max(dot)Williams(at)mflow(dot)com> wrote:

> I'm afraid pg_config is not part of the pgdg packages.

Connect (using psql or your favorite client) and run:

show debug_assertions;

-Kevin

Max Williams <Max(dot)Williams(at)mflow(dot)com> writes:
> I'm afraid pg_config is not part of the pgdg packages.

Sure it is. They might've put it in the -devel subpackage, though.

regards, tom lane

Ah, yes its OFF for 8.4.3 and ON for 8.4.4!

Can I just turn this off on 8.4.4 or is it a compile time option?
Also is this a mistake or intended? Perhaps I should tell the person who builds the pgdg packages??

Cheers,
Max

-----Original Message-----
From: Kevin Grittner [mailto:Kevin(dot)Grittner(at)wicourts(dot)gov]
Sent: 10 June 2010 16:16
To: Max Williams; pgsql-performance(at)postgresql(dot)org
Subject: Re: [PERFORM] Large (almost 50%!) performance drop after upgrading to 8.4.4?

Max Williams <Max(dot)Williams(at)mflow(dot)com> wrote:

> I'm afraid pg_config is not part of the pgdg packages.

Connect (using psql or your favorite client) and run:

show debug_assertions;

-Kevin

Max Williams <Max(dot)Williams(at)mflow(dot)com> writes:
> Ah, yes its OFF for 8.4.3 and ON for 8.4.4!

Hah.

> Can I just turn this off on 8.4.4 or is it a compile time option?

Well, you can turn it off, but that will only buy back part of the
cost (and not even the bigger part, I believe).

> Also is this a mistake or intended? Perhaps I should tell the person who builds the pgdg packages??

Yes, the folks at commandprompt need to be told about this. Loudly.
It's a serious packaging error.

regards, tom lane

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.

--
Álvaro Herrera <alvherre(at)commandprompt(dot)com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

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

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

--
Lacey Powers

The PostgreSQL Company - Command Prompt, Inc. 1.503.667.4564 ext 104
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

Max Williams wrote:
> Can I just turn this off on 8.4.4 or is it a compile time option

You can update your postgresql.conf to include:

debug_assertions = false

And restart the server. This will buy you back *some* of the
performance loss but not all of it. Will have to wait for corrected
packaged to make the issue completely go away.

--
Greg Smith 2ndQuadrant US Baltimore, MD
PostgreSQL Training, Services and Support
greg(at)2ndQuadrant(dot)com www.2ndQuadrant.us

Greg Smith <greg <at> 2ndquadrant.com> writes:

>
> Max Williams wrote:
> > Can I just turn this off on 8.4.4 or is it a compile time option
>
> You can update your postgresql.conf to include:
>
> debug_assertions = false
>
> And restart the server. This will buy you back *some* of the
> performance loss but not all of it. Will have to wait for corrected
> packaged to make the issue completely go away.
>

Ah! I am so thankful I found this thread. We've been having the same issues
described here. And when I do a SHOW debug_assertions I get:

postgres=# show debug_assertions;
debug_assertions
------------------
on
(1 row)

Can you let us know when the corrected packages have become available?

Regards,
John

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(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ None of us is going to be here forever. +

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(at)momjian(dot)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(at)momjian(dot)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(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ None of us is going to be here forever. +

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(at)commandprompt(dot)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 soon as 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(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ None of us is going to be here forever. +

Bruce Momjian <bruce(at)momjian(dot)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(at)momjian(dot)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(at)momjian(dot)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: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?

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