Thread: New dot releases
Hi, After / before 8.1 Beta 2, are there any plans to release new dot releases for the back branches? Regards, -- Devrim GUNDUZ Kivi Bilişim Teknolojileri - http://www.kivi.com.tr devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr http://www.gunduz.org
Devrim Gunduz <devrim@gunduz.org> writes:
> After / before 8.1 Beta 2, are there any plans to release new dot releases
> for the back branches?
Some day ;-)
What's holding up the back branches at the moment is that the gerbil
buildfarm member is showing failures in the 8.0 branch that started
right after I patched the vacuum/ctid-chain stuff. That probably
indicates a problem, but the owner of the machine has been completely
unhelpful about providing any information to track it down.
regards, tom lane
>What's holding up the back branches at the moment is that the gerbil >buildfarm member is showing failures in the 8.0 branch that started >right after I patched the vacuum/ctid-chain stuff. That probably >indicates a problem, but the owner of the machine has been completely >unhelpful about providing any information to track it down. > > I have a Solaris 9 machine on Sparc that I could let you have access to. Would that help? Sincerely, Joshua D. Drake > regards, tom lane > >---------------------------(end of broadcast)--------------------------- >TIP 5: don't forget to increase your free space map settings > > -- Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240 PostgreSQL Replication, Consulting, Custom Programming, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/
On Fri, Sep 16, 2005 at 07:57:08AM -0700, Joshua D. Drake wrote: > >What's holding up the back branches at the moment is that the gerbil > >buildfarm member is showing failures in the 8.0 branch that started > >right after I patched the vacuum/ctid-chain stuff. That probably > >indicates a problem, but the owner of the machine has been completely > >unhelpful about providing any information to track it down. > > > I have a Solaris 9 machine on Sparc that I could let you have > access to. Would that help? FWIW, I have a Solaris 9/sparc box with gcc 3.4.2 (same setup as gerbil) and have no problems with REL7_2_STABLE through HEAD. I'll test REL8_0_STABLE with gerbil's configure options when I get a chance. Most of gerbil's errors are: creating information schema ... Bus Error - core dumped but a few are: creating template1 database in /home/pgbuildfarm/build-farm-2.05/REL8_0_STABLE/pgsql.5942/src/test/regress/./tmp_check/data/base/1... FATAL: shmat(id=8326)failed: Not enough space -- Michael Fuhr
On Fri, Sep 16, 2005 at 09:28:39AM -0600, Michael Fuhr wrote: > FWIW, I have a Solaris 9/sparc box with gcc 3.4.2 (same setup as > gerbil) and have no problems with REL7_2_STABLE through HEAD. I'll > test REL8_0_STABLE with gerbil's configure options when I get a > chance. I just built REL8_0_STABLE with the following configure options (same as gerbil): ./configure --enable-cassert --enable-debug --enable-nls \ --enable-integer-datetimes --with-perl --with-python\ --with-openssl --with-pgport=5682 gmake check returned the following: ======================All 96 tests passed. ====================== -- Michael Fuhr
Hi, On Fri, 16 Sep 2005, Michael Fuhr wrote: > On Fri, Sep 16, 2005 at 09:28:39AM -0600, Michael Fuhr wrote: >> FWIW, I have a Solaris 9/sparc box with gcc 3.4.2 (same setup as >> gerbil) and have no problems with REL7_2_STABLE through HEAD. I'll >> test REL8_0_STABLE with gerbil's configure options when I get a >> chance. > > I just built REL8_0_STABLE with the following configure options > (same as gerbil): > > ./configure --enable-cassert --enable-debug --enable-nls \ > --enable-integer-datetimes --with-perl --with-python \ > --with-openssl --with-pgport=5682 > > gmake check returned the following: > > ====================== > All 96 tests passed. > ====================== So no need to hold the new dot releases? :) I want to work on new RPM sets and don't want to apply countless patches... :) Regards, -- Devrim GUNDUZ Kivi Bilişim Teknolojileri - http://www.kivi.com.tr devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr http://www.gunduz.org
Devrim GUNDUZ <devrim@gunduz.org> writes:
> So no need to hold the new dot releases? :)
I still object to releasing them until we find out what's going on
on gerbil. That machine was building 8.0 fine until the patch, and it's
failing consistently since then. To assume this is not our problem
would be the height of hubris.
regards, tom lane
On Mon, Sep 19, 2005 at 10:53:44AM -0400, Tom Lane wrote: > Devrim GUNDUZ <devrim@gunduz.org> writes: > > So no need to hold the new dot releases? :) > > I still object to releasing them until we find out what's going on > on gerbil. That machine was building 8.0 fine until the patch, and it's > failing consistently since then. To assume this is not our problem > would be the height of hubris. In an earlier message you said that "the owner of the machine has been completely unhelpful about providing any information to track it down." Is he not responding at all, or is he responding but with not enough information? Most of gerbil's failures are: creating information schema ... Bus Error - core dumped Is the message implying that the postgres process that initdb starts is dumping core? Any ideas on how the patch might cause that? The most recent failures are shmat(id=8326) failed: Not enough space and the default settings are selecting default max_connections ... 10 selecting default shared_buffers ... 50 Earlier tests that got as far as "creating information schema" had defaults lower than the maximums: selecting default max_connections ... 40 selecting default shared_buffers ... 700 Could the reduced settings (and thus what they imply about the amount of shared memory) be relevant? Could anything in the patch be affected by that? If you think it might be worthwhile, I could mess around with my box's shared memory settings and test it. Just looking for differences between gerbil and my box.... -- Michael Fuhr
On Mon, Sep 19, 2005 at 11:09:50PM -0600, Michael Fuhr wrote: > In an earlier message you said that "the owner of the machine has > been completely unhelpful about providing any information to track > it down." Is he not responding at all, or is he responding but > with not enough information? Yes. I had been working on this trying (unsucessfully) to get a working backtrace when I ended up with a bunch of other things on my plate. We now have a good backtrace. > Most of gerbil's failures are: > > creating information schema ... Bus Error - core dumped > > Is the message implying that the postgres process that initdb starts > is dumping core? Any ideas on how the patch might cause that? > > The most recent failures are > > shmat(id=8326) failed: Not enough space The shmat errors were because there were a bunch of shared memory segments hanging around, because they didn't get cleaned up from initdb coreing. The only real issue is the core dump, which an email has been sent to the list about. Sorry for the delay in tracking this down. -- Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461