Thread: Alpha release this week?
All,
We've got two locations and some individuals signed up for a test-fest
this weekend. Would it be possible to do an alpha release this week?
It would really help to be testing later code than Alpha4.
-- -- Josh Berkus PostgreSQL Experts Inc.
http://www.pgexperts.com
On Sun, Mar 28, 2010 at 4:40 PM, Josh Berkus <josh@agliodbs.com> wrote: > We've got two locations and some individuals signed up for a test-fest > this weekend. Would it be possible to do an alpha release this week? > It would really help to be testing later code than Alpha4. I'm willing to do the CVS bits, if that's helpful. Or maybe Peter wants to do it. Anyway I have no problem with the idea. ...Robert
Robert Haas wrote: > On Sun, Mar 28, 2010 at 4:40 PM, Josh Berkus <josh@agliodbs.com> wrote: >> We've got two locations and some individuals signed up for a test-fest >> this weekend. Would it be possible to do an alpha release this week? >> It would really help to be testing later code than Alpha4. > > I'm willing to do the CVS bits, if that's helpful. Or maybe Peter > wants to do it. Anyway I have no problem with the idea. or just use a specific recent snapshot and let people test that just in case it is not feasible doing a new alpha on short notice. Stefan
> or just use a specific recent snapshot and let people test that just in
> case it is not feasible doing a new alpha on short notice.
Doesn't work if we want to test it on windows. And snaphsots have more
compile dependancies than releases do.
Also ... this isn't short notice. I requested a new alpha, this week, 2
weeks ago.
-- -- Josh Berkus PostgreSQL Experts Inc.
http://www.pgexperts.com
On Mon, Mar 29, 2010 at 2:52 PM, Josh Berkus <josh@agliodbs.com> wrote: > >> or just use a specific recent snapshot and let people test that just in >> case it is not feasible doing a new alpha on short notice. > > Doesn't work if we want to test it on windows. And snaphsots have more > compile dependancies than releases do. > > Also ... this isn't short notice. I requested a new alpha, this week, 2 > weeks ago. Also, I already said I would do it (unless another committer wants to). Somebody just has to tell me what they want done and when. Presumably that means providing a patch to the release notes for me to check in, a date to make the branch, and where they want the tarball put. ...Robert
Robert Haas wrote: > On Mon, Mar 29, 2010 at 2:52 PM, Josh Berkus <josh@agliodbs.com> wrote: >>> or just use a specific recent snapshot and let people test that just in >>> case it is not feasible doing a new alpha on short notice. >> Doesn't work if we want to test it on windows. And snaphsots have more >> compile dependancies than releases do. >> >> Also ... this isn't short notice. I requested a new alpha, this week, 2 >> weeks ago. > > Also, I already said I would do it (unless another committer wants > to). Somebody just has to tell me what they want done and when. > Presumably that means providing a patch to the release notes for me to > check in, a date to make the branch, and where they want the tarball > put. yeah but you also need people changing the website - and probably more important given that josh wants windows as well help from dave for doing a new windows installer :) Stefan
On Mon, Mar 29, 2010 at 4:40 PM, Stefan Kaltenbrunner <stefan@kaltenbrunner.cc> wrote: > yeah but you also need people changing the website - and probably more > important given that josh wants windows as well help from dave for doing a > new windows installer :) True... well, I can't help with those bits. :-) ...Robert
On sön, 2010-03-28 at 19:22 -0400, Robert Haas wrote: > On Sun, Mar 28, 2010 at 4:40 PM, Josh Berkus <josh@agliodbs.com> wrote: > > We've got two locations and some individuals signed up for a test-fest > > this weekend. Would it be possible to do an alpha release this week? > > It would really help to be testing later code than Alpha4. > > I'm willing to do the CVS bits, if that's helpful. Or maybe Peter > wants to do it. Anyway I have no problem with the idea. > > ...Robert > Feel free to do it. It's documented at <http://wiki.postgresql.org/wiki/Alpha_release_process>. Ask me if something is unclear. But as was said downthread, getting someone to do the Windows installer would be good.
<p>Last i heard from Dave on that topic is that there's no chance of that happening that quickly. He's on a plane now butI'm sure he'll confirm that when he lands. <p>/Magnus<p><blockquote type="cite">On Mar 29, 2010 6:14 PM, "Peter Eisentraut"<<a href="mailto:peter_e@gmx.net">peter_e@gmx.net</a>> wrote:<br /><br /><p><font color="#500050">On sön,2010-03-28 at 19:22 -0400, Robert Haas wrote:<br /> > On Sun, Mar 28, 2010 at 4:40 PM, Josh Berkus...</font>Feel freeto do it. It's documented at<br /> <<a href="http://wiki.postgresql.org/wiki/Alpha_release_process" target="_blank">http://wiki.postgresql.org/wiki/Alpha_release_process</a>>. Ask me if<br /> something is unclear.<br /><br/> But as was said downthread, getting someone to do the Windows installer<br /> would be good.<br /><p><font color="#500050"><br/><br />-- <br />Sent via pgsql-hackers mailing list (<a href="mailto:pgsql-hackers@postgresql.org">pgsql-hackers@postgresql.org</a>)<br/>To make changes to your sub...</font></blockquote>
Josh Berkus escribió: > And snaphsots have more compile dependancies than releases do. As far as I know, a snapshot is identical to a "release" in that regard. If they are not, that's a bug and we can fix it before weekend. -- Alvaro Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc.
Alvaro Herrera wrote: > Josh Berkus escribió: > >> And snaphsots have more compile dependancies than releases do. > > As far as I know, a snapshot is identical to a "release" in that regard. > If they are not, that's a bug and we can fix it before weekend. yeah - snapshots do have the same compile time dependencies as release tarballs have. Stefan
On 3/29/10 5:04 PM, Magnus Hagander wrote:
> Last i heard from Dave on that topic is that there's no chance of that
> happening that quickly. He's on a plane now but I'm sure he'll confirm
> that when he lands.
That means that we'll be doing the test-fest using Alpha4, materially.
Which is annoying because it means we'll be catching a lot of bugs which
are already fixed. However, it's pretty much impossible for me to
coordinate 25 volunteers getting the *same* daily snapshot. And we need
to test on Windows, since it has all kinds of special issues.
I think my big goal for 9.1 is going to be to fix our testing procedure,
or rather total lack of a procedure. We've got development
systematized, now it's time for testing. I'm just sorry that the press
of work kept me from really doing it this time around.
I think we could be getting from alpha to beta in 6 weeks if we actually
had a schedule and some real testing goals.
-- -- Josh Berkus PostgreSQL Experts Inc.
http://www.pgexperts.com
On Tue, Mar 30, 2010 at 4:43 PM, Josh Berkus <josh@agliodbs.com> wrote: > On 3/29/10 5:04 PM, Magnus Hagander wrote: >> Last i heard from Dave on that topic is that there's no chance of that >> happening that quickly. He's on a plane now but I'm sure he'll confirm >> that when he lands. > > That means that we'll be doing the test-fest using Alpha4, materially. > Which is annoying because it means we'll be catching a lot of bugs which > are already fixed. However, it's pretty much impossible for me to > coordinate 25 volunteers getting the *same* daily snapshot. And we need > to test on Windows, since it has all kinds of special issues. > > I think my big goal for 9.1 is going to be to fix our testing procedure, > or rather total lack of a procedure. We've got development > systematized, now it's time for testing. I'm just sorry that the press > of work kept me from really doing it this time around. > > I think we could be getting from alpha to beta in 6 weeks if we actually > had a schedule and some real testing goals. At the risk of being blunt, AFAICT, the delay in getting to beta has little or nothing to do with testing and everything to do with the fact that streaming replication got committed with a long list of open items two months ago, and many of them haven't been fixed yet. Hot Standby has a few warts too, but I think Simon has done a better job cleaning up the loose ends there (with help from Tom and Heikki), no doubt because he got it committed two months sooner than SR. From a project management point of view, it seems to me that we shouldn't commit major patches late in the release cycle unless someone has the time to actually get them finished and stable. If Streaming Replication were any other patch, we would have reverted it a month ago. As it is, it looks like we're going to be waiting until Heikki has time to deal with the issues, because it doesn't look like any of the other committers are able/willing to help. ...Robert
On Wed, Mar 31, 2010 at 7:01 AM, Robert Haas <robertmhaas@gmail.com> wrote: > At the risk of being blunt, AFAICT, the delay in getting to beta has > little or nothing to do with testing and everything to do with the > fact that streaming replication got committed with a long list of open > items two months ago, and many of them haven't been fixed yet. Hot > Standby has a few warts too, but I think Simon has done a better job > cleaning up the loose ends there (with help from Tom and Heikki), no > doubt because he got it committed two months sooner than SR. From a > project management point of view, it seems to me that we shouldn't > commit major patches late in the release cycle unless someone has the > time to actually get them finished and stable. If Streaming > Replication were any other patch, we would have reverted it a month > ago. As it is, it looks like we're going to be waiting until Heikki > has time to deal with the issues, because it doesn't look like any of > the other committers are able/willing to help. I believe that anyone except Heikki & me can deal with the following issues since they started with SR but actually are not tied up to SR ;) * dblink and walreceiver are not interruptible on win32 http://archives.postgresql.org/pgsql-hackers/2010-01/msg01672.php http://archives.postgresql.org/pgsql-hackers/2010-03/msg00413.php * smart shutdown during recovery gets stuck http://archives.postgresql.org/pgsql-hackers/2010-01/msg02044.php http://archives.postgresql.org/pgsql-hackers/2010-03/msg01208.php * pg_xlogfile_name() might report the wrong name http://archives.postgresql.org/pgsql-hackers/2010-01/msg01806.php Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center
Josh Berkus wrote: > On 3/29/10 5:04 PM, Magnus Hagander wrote: >> Last i heard from Dave on that topic is that there's no chance of that >> happening that quickly. He's on a plane now but I'm sure he'll confirm >> that when he lands. > > That means that we'll be doing the test-fest using Alpha4, materially. > Which is annoying because it means we'll be catching a lot of bugs which > are already fixed. However, it's pretty much impossible for me to > coordinate 25 volunteers getting the *same* daily snapshot. And we need > to test on Windows, since it has all kinds of special issues. well this is actually the first release cycle where we even HAD alpha releases - as for the snapsho thing I cannot see why you could not download a snpashot on your own, put it somewhere (like a wiki page) and send out an email to all the volunteers and ask them to use at least that one if building from source... Stefan
On Tue, Mar 30, 2010 at 1:04 AM, Magnus Hagander <magnus@hagander.net> wrote: > Last i heard from Dave on that topic is that there's no chance of that > happening that quickly. He's on a plane now but I'm sure he'll confirm that > when he lands. Not with any amount of testing as we'd normally give any build before releasing it anyway. I can certainly stuff a tarball into the new build machine and see what comes out the next morning. -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com
Dave,
> Not with any amount of testing as we'd normally give any build before
> releasing it anyway. I can certainly stuff a tarball into the new
> build machine and see what comes out the next morning.
That would be good enough for Saturday; we're going to test it after
all. Let me know which snapshot day you grab, so we can have the same
snapshot-day for Windows and other platforms.
-- -- Josh Berkus PostgreSQL Experts Inc.
http://www.pgexperts.com
On Wed, Mar 31, 2010 at 6:46 PM, Josh Berkus <josh@agliodbs.com> wrote: > Dave, > >> Not with any amount of testing as we'd normally give any build before >> releasing it anyway. I can certainly stuff a tarball into the new >> build machine and see what comes out the next morning. > > That would be good enough for Saturday; we're going to test it after > all. Let me know which snapshot day you grab, so we can have the same > snapshot-day for Windows and other platforms. Oh, you're wanting to use an automated snapshot? There used to be some differences in those tarballs (when compared to real releases) that will probably cause the build system to fall over. If you can get a proper alpha 5 tarball created, that would be preferrable. -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com
On Wed, Mar 31, 2010 at 2:33 PM, Dave Page <dpage@pgadmin.org> wrote: > On Wed, Mar 31, 2010 at 6:46 PM, Josh Berkus <josh@agliodbs.com> wrote: >> Dave, >> >>> Not with any amount of testing as we'd normally give any build before >>> releasing it anyway. I can certainly stuff a tarball into the new >>> build machine and see what comes out the next morning. >> >> That would be good enough for Saturday; we're going to test it after >> all. Let me know which snapshot day you grab, so we can have the same >> snapshot-day for Windows and other platforms. > > Oh, you're wanting to use an automated snapshot? There used to be some > differences in those tarballs (when compared to real releases) that > will probably cause the build system to fall over. If you can get a > proper alpha 5 tarball created, that would be preferrable. I can snap a tarball tonight if you want. I'm going to be leaving town tomorrow afternoon, though. ...Robert
On Wed, 2010-03-31 at 10:46 -0700, Josh Berkus wrote: > > Not with any amount of testing as we'd normally give any build > before > > releasing it anyway. I can certainly stuff a tarball into the new > > build machine and see what comes out the next morning. > > That would be good enough for Saturday; we're going to test it after > all. Let me know which snapshot day you grab, so we can have the same > snapshot-day for Windows and other platforms. FWIW, I can release RPMs based on the same snapshot in an hour after I get the tarball. -- 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
On Wed, Mar 31, 2010 at 7:52 PM, Robert Haas <robertmhaas@gmail.com> wrote: > I can snap a tarball tonight if you want. I'm going to be leaving > town tomorrow afternoon, though. Works for me. I'll stuff it into our shiny new 9.0 build machine tomorrow. -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com
Robert,
> I can snap a tarball tonight if you want. I'm going to be leaving
> town tomorrow afternoon, though.
Please do.
-- -- Josh Berkus PostgreSQL Experts Inc.
http://www.pgexperts.com
On Wed, Mar 31, 2010 at 4:39 PM, Josh Berkus <josh@agliodbs.com> wrote: >> I can snap a tarball tonight if you want. I'm going to be leaving >> town tomorrow afternoon, though. > > Please do. If someone could email me off list where they would like the tarball put, with login credentials, I will put it there. Otherwise I will be creative. ...Robert
On Wed, Mar 31, 2010 at 3:29 PM, Dave Page <dpage@pgadmin.org> wrote: > On Wed, Mar 31, 2010 at 7:52 PM, Robert Haas <robertmhaas@gmail.com> wrote: >> I can snap a tarball tonight if you want. I'm going to be leaving >> town tomorrow afternoon, though. > > Works for me. I'll stuff it into our shiny new 9.0 build machine tomorrow. Marc is going to set up me up with access to a more appropriate location, but in the meantime, here's alpha5: https://commitfest.postgresql.org/release/ sha1sum: 54c1f3fda64c675ee3882c0f5be3fdc44e6d0323 postgresql-9.0alpha5.tar.bz2 a3099fc8090f5793c3dd7b9ee5dae7a622b29d87 postgresql-9.0alpha5.tar.gz ...Robert
On Wed, Mar 31, 2010 at 10:34 PM, Robert Haas <robertmhaas@gmail.com> wrote: > On Wed, Mar 31, 2010 at 3:29 PM, Dave Page <dpage@pgadmin.org> wrote: >> On Wed, Mar 31, 2010 at 7:52 PM, Robert Haas <robertmhaas@gmail.com> wrote: >>> I can snap a tarball tonight if you want. I'm going to be leaving >>> town tomorrow afternoon, though. >> >> Works for me. I'll stuff it into our shiny new 9.0 build machine tomorrow. > > Marc is going to set up me up with access to a more appropriate > location, but in the meantime, here's alpha5: > > https://commitfest.postgresql.org/release/ > > sha1sum: > > 54c1f3fda64c675ee3882c0f5be3fdc44e6d0323 postgresql-9.0alpha5.tar.bz2 > a3099fc8090f5793c3dd7b9ee5dae7a622b29d87 postgresql-9.0alpha5.tar.gz This stuff is now also at: ftp://developer.postgresql.org/pub/source/9.0alpha5/ ...Robert
On Thu, Apr 1, 2010 at 5:24 AM, Robert Haas <robertmhaas@gmail.com> wrote: > This stuff is now also at: > > ftp://developer.postgresql.org/pub/source/9.0alpha5/ Thanks Robert. We're working on this, but it seems that changes in the PG build have broken the debugger again. Hopefully we can get it sorted before the holidays start tomorrow. -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com
On Thu, Apr 1, 2010 at 2:31 PM, Dave Page <dpage@pgadmin.org> wrote: > On Thu, Apr 1, 2010 at 5:24 AM, Robert Haas <robertmhaas@gmail.com> wrote: >> This stuff is now also at: >> >> ftp://developer.postgresql.org/pub/source/9.0alpha5/ > > Thanks Robert. We're working on this, but it seems that changes in the > PG build have broken the debugger again. Hopefully we can get it > sorted before the holidays start tomorrow. OK, there are builds at http://developer.pgadmin.org/~dpage/ Note that these are from an entirely new build machine for 9.0. There are new build OS's, new compilers, updated dependencies... in other words, expect something to go wrong. I did briefly test the Windows version - the server installed and ran OK, but pgAdmin 1.8 doesn't like PG 9.0 -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com
Robert, Dave,
Thanks so much for building these.
Hopefully we'll get a good turnout and get a lot of things tested.
-- -- Josh Berkus PostgreSQL Experts Inc.
http://www.pgexperts.com
Guys,
Hmmm. I appear to have had a compile error with that alpha5 tarball,
in elog.c. No special options on compile, except an alternate directory
and port.
Ubunutu 9.10 server
GCC 4.3.3
Tries both:
./configure --with-pgport=5490 --prefix=/usr/local/pgsql/9.0/
and:
./configure --with-pgport=5490 --prefix=/usr/local/pgsql/9.0/
--enable-debug -enable-cassert
make[4]: Entering directory
`/usr/local/src/postgresql-9.0alpha5/src/backend/utils/error'
gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith
-Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing
-fwrapv -Werror -I../../../../src/include -D_GNU_SOURCE -c -o assert.o
assert.c
gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith
-Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing
-fwrapv -Werror -I../../../../src/include -D_GNU_SOURCE -c -o elog.o
elog.c
cc1: warnings being treated as errors
elog.c: In function ‘write_console’:
elog.c:1698: error: ignoring return value of ‘write’, declared with
attribute warn_unused_result
elog.c: In function ‘write_pipe_chunks’:
elog.c:2390: error: ignoring return value of ‘write’, declared with
attribute warn_unused_result
elog.c:2399: error: ignoring return value of ‘write’, declared with
attribute warn_unused_result
make[4]: *** [elog.o] Error 1
-- -- Josh Berkus PostgreSQL Experts Inc.
http://www.pgexperts.com
Josh Berkus <josh@agliodbs.com> writes:
> Hmmm. I appear to have had a compile error with that alpha5 tarball,
> in elog.c. No special options on compile, except an alternate directory
> and port.
No, you stuck in -Werror. Don't do that on bleeding-edge gcc (or
bleeding-edge anything).
regards, tom lane
On 4/1/10 9:57 PM, Tom Lane wrote:
> Josh Berkus <josh@agliodbs.com> writes:
>> Hmmm. I appear to have had a compile error with that alpha5 tarball,
>> in elog.c. No special options on compile, except an alternate directory
>> and port.
>
> No, you stuck in -Werror. Don't do that on bleeding-edge gcc (or
> bleeding-edge anything).
I didn't actually. Must be set by default on Ubuntu's gcc?
(goes looking for a way to disable it ...)
-- -- Josh Berkus PostgreSQL Experts Inc.
http://www.pgexperts.com
> No, you stuck in -Werror. Don't do that on bleeding-edge gcc (or
> bleeding-edge anything).
Found it ... Robert, you stuck a -Werror in the gzip file you uploaded
(but not, for some reason, the bzip).
-- -- Josh Berkus PostgreSQL Experts Inc.
http://www.pgexperts.com
Tom, Robert, etc.
Ok, this issue seems to be specific to some versions of gcc. Note that
in testing this nobody enabled any special compile or environment
variables of any kind, so if there's a -Werror where it shouldn't be,
it's in our code.
Succeeds on:
Red Hat, gcc 4.4.3
OSX, gcc 4.2.1
Debian, gcc 4.3.2
FreeBSD, gcc 4.2.1
Fails on:
Ubuntu, gcc 4.3.3
Ubuntu, gcc 4.4.1
OSX 10.5, gcc 4.0.1*
I'd assume this was some kind of Ubuntu thing, except that I got it to
fail on OSX as well. Ideas?
-- -- Josh Berkus PostgreSQL Experts Inc.
http://www.pgexperts.com
* fails at:
gcc -no-cpp-precomp -O2 -Wall -Wmissing-prototypes -Wpointer-arith
-Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing
-fwrapv -Werror -I../../../../src/include -c -o dbsize.o dbsize.c
cc1: warnings being treated as errors
dbsize.c: In function ‘pg_relation_filepath’:
dbsize.c:577: warning: ‘rnode.spcNode’ may be used uninitialized in this
function
dbsize.c:577: warning: ‘rnode.dbNode’ may be used uninitialized in this
function
make[4]: *** [dbsize.o] Error 1
make[3]: *** [adt-recursive] Error 2
make[2]: *** [utils-recursive] Error 2
make[1]: *** [all] Error 2
make: *** [all] Error 2
Josh Berkus <josh@agliodbs.com> wrote: > Ok, this issue seems to be specific to some versions of gcc. Note that > in testing this nobody enabled any special compile or environment > variables of any kind, so if there's a -Werror where it shouldn't be, > it's in our code. Hi, cygwin also has -Werror in default, and build was failed with a warning: $ uname -a CYGWIN_NT-5.1 <name> 1.7.2(0.225/5/3) 2010-03-24 21:12 i686 Cygwin gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement-Wendif-labels -fno-strict-aliasing -fwrapv-Werror -DDEF_PGPORT=5432 -I../../. ./src/interfaces/libpq -I../../../src/include -c -o pg_ctl.o pg_ctl.c pg_ctl.c: In function `pgwin32_CommandLine': pg_ctl.c:1083: warning: `cygwin_conv_to_full_win32_path' is deprecated (declaredat /usr/include/sys/cygwin.h:52) make[3]: *** [pg_ctl.o] Error 1 Any objections for the following fix? Index: src/bin/pg_ctl/pg_ctl.c =================================================================== --- src/bin/pg_ctl/pg_ctl.c (HEAD) +++ src/bin/pg_ctl/pg_ctl.c (fixed) @@ -1080,7 +1080,7 @@#ifdef __CYGWIN__ /* need to convert to windows path */ - cygwin_conv_to_full_win32_path(cmdLine, buf); + cygwin_conv_path(CCP_POSIX_TO_WIN_A, cmdLine, buf, sizeof(buf)); strcpy(cmdLine, buf);#endif Regards, --- Takahiro Itagaki NTT Open Source Software Center
On Apr 2, 2010, at 2:28 AM, Josh Berkus <josh@agliodbs.com> wrote: > Tom, Robert, etc. > > Ok, this issue seems to be specific to some versions of gcc. Note > that > in testing this nobody enabled any special compile or environment > variables of any kind, so if there's a -Werror where it shouldn't be, > it's in our code. > > Succeeds on: > Red Hat, gcc 4.4.3 > OSX, gcc 4.2.1 > Debian, gcc 4.3.2 > FreeBSD, gcc 4.2.1 > > Fails on: > Ubuntu, gcc 4.3.3 > Ubuntu, gcc 4.4.1 > OSX 10.5, gcc 4.0.1* > > I'd assume this was some kind of Ubuntu thing, except that I got it to > fail on OSX as well. I can't easily get on line to check this just now, but did I accidentally bundle my Makefile.custom into this tarball? ...Robert
On fre, 2010-04-02 at 04:48 -0400, Robert Haas wrote: > I can't easily get on line to check this just now, but did I > accidentally bundle my Makefile.custom into this tarball? Uhum, if you had followed http://wiki.postgresql.org/wiki/Alpha_release_process then this couldn't have happened.
On tor, 2010-04-01 at 23:28 -0700, Josh Berkus wrote: > Fails on: > Ubuntu, gcc 4.3.3 > Ubuntu, gcc 4.4.1 > OSX 10.5, gcc 4.0.1* Ubuntu builds with hardening options by default, which cause several warnings. Not sure about the OSX issue.
On Fri, Apr 2, 2010 at 9:48 AM, Robert Haas <robertmhaas@gmail.com> wrote:. > > I can't easily get on line to check this just now, but did I > accidentally bundle my Makefile.custom into this tarball? D'oh! That explains the pain I had building the binaries (mainly the add-ons). We assumed that -Werror was an intentional addition in 9.0a5... -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com
On Apr 2, 2010, at 5:18 AM, Peter Eisentraut <peter_e@gmx.net> wrote: > On fre, 2010-04-02 at 04:48 -0400, Robert Haas wrote: >> I can't easily get on line to check this just now, but did I >> accidentally bundle my Makefile.custom into this tarball? > > Uhum, if you had followed > http://wiki.postgresql.org/wiki/Alpha_release_process then this > couldn't > have happened. Forgive me for being a little annoyed here, but I actually did follow that document quite closely. Unfortunately it omits to mention a few key points. What actually happened here is that I discovered that I couldn't run "make distcheck" on a clean source tree. configure needs to be run first, and the fine documentation makes no mention of what options should be used. So naturally I just ran my dev-configure alias, which also creates a one-line Makefile.custom. Now maybe I should have realized that this was going to lead to bad things happening, but I didn't. The wiki page in fact makes no reference at all to the state that one's source tree should be in when doing all of this; it just didn't occur to me that any random crap I happened to have lying around there was going to get shipped. I'm obviously very sorry for the hassle and frustration caused by this mistake, especially to Dave Page, but hopefully you understand that I was trying rather hard to get this right; and perhaps the Wiki page can also be improved to mention some of these details. ...Robert
On fre, 2010-04-02 at 06:42 -0400, Robert Haas wrote: > Forgive me for being a little annoyed here, but I actually did follow > that document quite closely. Unfortunately it omits to mention a few > key points. Sorry, I had suspected that you didn't do a clean cvs export. It was a frequent problem in the old days. > What actually happened here is that I discovered that I couldn't run > "make distcheck" on a clean source tree. configure needs to be run > first, and the fine documentation makes no mention of what options > should be used. Doesn't matter. Just ./configure is enough. > So naturally I just ran my dev-configure alias, which > also creates a one-line Makefile.custom. Now maybe I should have > realized that this was going to lead to bad things happening, but I > didn't. Ah, well, nothing can guard against that. ;-) > The wiki page in fact makes no reference at all to the state > that one's source tree should be in when doing all of this; it just > didn't occur to me that any random crap I happened to have lying > around there was going to get shipped. The state is that after a cvs export. > I'm obviously very sorry for the hassle and frustration caused by this > mistake, especially to Dave Page, but hopefully you understand that I > was trying rather hard to get this right; and perhaps the Wiki page > can also be improved to mention some of these details. Please add your findings.
Hi, I use Ubuntu 9.04 (GCC 4.3.3). Build was failed too. I was able to compile with some small correction. All are the one that relates only to the return value of write() and fgets(). (1) src/backend/utils/error/elog.c elog.c: In function 'write_console': elog.c:1698: error: ignoring return value of 'write', declared with attribute warn_unused_result elog.c: In function 'write_pipe_chunks': elog.c:2390: error: ignoring return value of 'write', declared with attribute warn_unused_result elog.c:2399: error: ignoring return value of 'write', declared with attribute warn_unused_result (2) src/interfaces/libpq/fe-connect.c fe-connect.c: In function 'PasswordFromFile': fe-connect.c:4403: error: ignoring return value of 'fgets', declared with attribute warn_unused_result (3) src/port/common.c common.c: In function 'handle_sigint': common.c:247: error: ignoring return value of 'write', declared with attribute warn_unused_result common.c:250: error: ignoring return value of 'write', declared with attribute warn_unused_result common.c:251: error: ignoring return value of 'write', declared with attribute warn_unused_result (4) src/bin/psql/prompt.c prompt.c: In function 'get_prompt': prompt.c:255: error: ignoring return value of 'fgets', declared with attribute warn_unused_result Regards, Genie Japo > Guys, > > Hmmm. I appear to have had a compile error with that alpha5 tarball, > in elog.c. No special options on compile, except an alternate directory > and port. > > Ubunutu 9.10 server > GCC 4.3.3 > Tries both: > ./configure --with-pgport=5490 --prefix=/usr/local/pgsql/9.0/ > and: > ./configure --with-pgport=5490 --prefix=/usr/local/pgsql/9.0/ > --enable-debug -enable-cassert > > make[4]: Entering directory > `/usr/local/src/postgresql-9.0alpha5/src/backend/utils/error' > gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith > -Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing > -fwrapv -Werror -I../../../../src/include -D_GNU_SOURCE -c -o assert.o > assert.c > gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith > -Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing > -fwrapv -Werror -I../../../../src/include -D_GNU_SOURCE -c -o elog.o > elog.c > cc1: warnings being treated as errors > elog.c: In function ‘write_console’: > elog.c:1698: error: ignoring return value of ‘write’, declared with > attribute warn_unused_result > elog.c: In function ‘write_pipe_chunks’: > elog.c:2390: error: ignoring return value of ‘write’, declared with > attribute warn_unused_result > elog.c:2399: error: ignoring return value of ‘write’, declared with > attribute warn_unused_result > make[4]: *** [elog.o] Error 1 > > -- > -- Josh Berkus > PostgreSQL Experts Inc. > http://www.pgexperts.com >
On Apr 2, 2010, at 2:28 AM, Josh Berkus <josh@agliodbs.com> wrote: > Tom, Robert, etc. > > Ok, this issue seems to be specific to some versions of gcc. Note > that > in testing this nobody enabled any special compile or environment > variables of any kind, so if there's a -Werror where it shouldn't be, > it's in our code. > > Succeeds on: > Red Hat, gcc 4.4.3 > OSX, gcc 4.2.1 > Debian, gcc 4.3.2 > FreeBSD, gcc 4.2.1 > > Fails on: > Ubuntu, gcc 4.3.3 > Ubuntu, gcc 4.4.1 > OSX 10.5, gcc 4.0.1* > > I'd assume this was some kind of Ubuntu thing, except that I got it to > fail on OSX as well. I can't easily get on line to check this just now, but did I accidentally bundle my Makefile.custom into this tarball? ...Robert
Robert,
> I'm obviously very sorry for the hassle and frustration caused by this
> mistake, especially to Dave Page, but hopefully you understand that I
> was trying rather hard to get this right; and perhaps the Wiki page
> can also be improved to mention some of these details.
Bound to happen the first time someone other than Peter did the
bundling. Which was one of the points of the Alphas ... to get more
people familiar with the process.
Anyway, do you think you could put up replacement tarballs today? I'll
remove Makefile.custom and see if that fixes what I have ...
-- -- Josh Berkus PostgreSQL Experts Inc.
http://www.pgexperts.com
Josh Berkus <josh@agliodbs.com> wrote: > Robert, > do you think you could put up replacement tarballs today? If you don't hear from him soon, perhaps he's traveling: http://archives.postgresql.org/pgsql-hackers/2010-03/msg01298.php -Kevin
Hello, I'd like to put myself forward to test Dave's alpha5 windows binaries tomorrow. I use that platform for about 75% of my pg work, and others tend to have limited enthusiasm for it (as I guess I would if I had the luxury of being able to), so that seems to be where I would be of most use. I seem to recall Josh complaining about a lack of windows testers too. What areas are of particular concern? I've been following 9.0's development from only a fairly high level. I suppose I'll try out my 8.4 app, which uses dblink and hstore, on 9.0 alpha5 and see if anything breaks, and play around with the features that are new to 9.0, as outlined on the postgres wiki for the "SFPUG Beta Test Day". This seems a little bit haphazard though. Could someone give me some additional direction? You should be aware that I'm capable of building postgres on windows, if that's useful. I might run the libpqxx 3.1 tests too, if that helps. Regards, Peter Geoghegan
On Apr 2, 2010, at 5:18 AM, Peter Eisentraut <peter_e@gmx.net> wrote: > On fre, 2010-04-02 at 04:48 -0400, Robert Haas wrote: >> I can't easily get on line to check this just now, but did I >> accidentally bundle my Makefile.custom into this tarball? > > Uhum, if you had followed > http://wiki.postgresql.org/wiki/Alpha_release_process then this > couldn't > have happened. Forgive me for being a little annoyed here, but I actually did follow that document quite closely. Unfortunately it omits to mention a few key points. What actually happened here is that I discovered that I couldn't run "make distcheck" on a clean source tree. configure needs to be run first, and the fine documentation makes no mention of what options should be used. So naturally I just ran my dev-configure alias, which also creates a one-line Makefile.custom. Now maybe I should have realized that this was going to lead to bad things happening, but I didn't. The wiki page in fact makes no reference at all to the state that one's source tree should be in when doing all of this; it just didn't occur to me that any random crap I happened to have lying around there was going to get shipped. I'm obviously very sorry for the hassle and frustration caused by this mistake, especially to Dave Page, but hopefully you understand that I was trying rather hard to get this right; and perhaps the Wiki page can also be improved to mention some of these details. ...Robert
On Apr 2, 2010, at 12:34 PM, Kevin Grittner <Kevin.Grittner@wicourts.gov> wrote: > Josh Berkus <josh@agliodbs.com> wrote: > >> Robert, > >> do you think you could put up replacement tarballs today? > > If you don't hear from him soon, perhaps he's traveling: > > http://archives.postgresql.org/pgsql-hackers/2010-03/msg01298.php Yeah, sorry, I'm not going to have ssh until Sunday, as previously mentioned. But removing src/Makefile.custom ought to do it. Or perhaps someone else can re-export the tag. ...Robert
Peter, Thanks! Great to have you participating! > I suppose I'll try out my 8.4 app, which uses dblink and hstore, on > 9.0 alpha5 and see if anything breaks, and play around with the > features that are new to 9.0, as outlined on the postgres wiki for the > "SFPUG Beta Test Day". This seems a little bit haphazard though. Could > someone give me some additional direction? I'm in the process of writing up more suggested tests. I started with pgbench performance comparisons: http://wiki.postgresql.org/wiki/Pgbenchtesting Also, we'll have a live video link and chat channel (per wiki page) for tommorrow, so if you want to follow along/ask questions, you can. -- -- Josh Berkus PostgreSQL Experts Inc. http://www.pgexperts.com
On Apr 2, 2010, at 12:34 PM, Kevin Grittner <Kevin.Grittner@wicourts.gov> wrote: > Josh Berkus <josh@agliodbs.com> wrote: > >> Robert, > >> do you think you could put up replacement tarballs today? > > If you don't hear from him soon, perhaps he's traveling: > > http://archives.postgresql.org/pgsql-hackers/2010-03/msg01298.php Yeah, sorry, I'm not going to have ssh until Sunday, as previously mentioned. But removing src/Makefile.custom ought to do it. Or perhaps someone else can re-export the tag. ...Robert
On Fri, Apr 2, 2010 at 2:44 PM, Robert Haas <robertmhaas@gmail.com> wrote: > On Apr 2, 2010, at 12:34 PM, Kevin Grittner > <Kevin.Grittner@wicourts.gov> wrote: >> Josh Berkus <josh@agliodbs.com> wrote: >> >>> Robert, >> >>> do you think you could put up replacement tarballs today? >> >> If you don't hear from him soon, perhaps he's traveling: >> >> http://archives.postgresql.org/pgsql-hackers/2010-03/msg01298.php > > Yeah, sorry, I'm not going to have ssh until Sunday, as previously > mentioned. But removing src/Makefile.custom ought to do it. Or > perhaps someone else can re-export the tag. I have uploaded corrected tarballs alongside the originals. ftp://developer.postgresql.org/pub/source/9.0alpha5/ ...Robert
Takahiro Itagaki <itagaki.takahiro@oss.ntt.co.jp> writes:
> Any objections for the following fix?
> - cygwin_conv_to_full_win32_path(cmdLine, buf);
> + cygwin_conv_path(CCP_POSIX_TO_WIN_A, cmdLine, buf, sizeof(buf));
Buildfarm member brown_bat didn't like this. Seeing that that's the
*only* active cygwin buildfarm member, that's not a good percentage.
regards, tom lane
On fre, 2010-04-02 at 14:44 -0400, Robert Haas wrote: > On Apr 2, 2010, at 12:34 PM, Kevin Grittner > <Kevin.Grittner@wicourts.gov> wrote: > > Josh Berkus <josh@agliodbs.com> wrote: > > > >> Robert, > > > >> do you think you could put up replacement tarballs today? > > > > If you don't hear from him soon, perhaps he's traveling: > > > > http://archives.postgresql.org/pgsql-hackers/2010-03/msg01298.php > > Yeah, sorry, I'm not going to have ssh until Sunday, as previously > mentioned. But removing src/Makefile.custom ought to do it. Or > perhaps someone else can re-export the tag. I could give it a shot, but a) The files on the FTP server master are not group writable, so I can't overwrite them. (Most are not, apparently a general problem.) b) The tag isn't actually version-stamped. configure/configure.in still say 9.0devel. Maybe it's best to delete everything so the "test fest" or whatever tomorrow doesn't trip over this. But see a).
Peter Eisentraut <peter_e@gmx.net> writes: > b) The tag isn't actually version-stamped. configure/configure.in still > say 9.0devel. Sure, because the tag is on a branch. According to the commit message that went by, Robert did that correctly: http://archives.postgresql.org/pgsql-committers/2010-03/msg00378.php regards, tom lane
On Apr 2, 2010, at 6:07 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Peter Eisentraut <peter_e@gmx.net> writes: >> b) The tag isn't actually version-stamped. configure/configure.in >> still >> say 9.0devel. > > Sure, because the tag is on a branch. According to the commit message > that went by, Robert did that correctly: > > http://archives.postgresql.org/pgsql-committers/2010-03/msg00378.php I just took the patch Peter applied for alpha4 and ran it through sed, applied the result, and sanity it. ...Robert
Josh Berkus wrote: > I started with pgbench performance comparisons: > http://wiki.postgresql.org/wiki/Pgbenchtesting > I'd already created http://wiki.postgresql.org/wiki/Regression_Testing_with_pgbench for this purpose, and it looks like you started where I ended that, more or less, which is good because you didn't duplicate anything I'd already written. I just recently finished a full exploration of how the multi-threaded pgbench ends up working in practice, and will update/merge those two as part of that once I get the full data published where people can look at it. I've given up on expecting ad-hoc pgbench testing done without an extremely clear methodology to produce a lot of data, it's tough to get useful results out of that without a clear plan to follow for finding useful data points. -- Greg Smith 2ndQuadrant US Baltimore, MD PostgreSQL Training, Services and Support greg@2ndQuadrant.com www.2ndQuadrant.us
Greg, > http://wiki.postgresql.org/wiki/Regression_Testing_with_pgbench for this > purpose, and it looks like you started where I ended that, more or less, > which is good because you didn't duplicate anything I'd already > written. Lucky! I didn't find that one when I looked. FWIW, the new pgbench has been great for testing. -- -- Josh Berkus PostgreSQL Experts Inc. http://www.pgexperts.com
Tom Lane <tgl@sss.pgh.pa.us> wrote: > > - cygwin_conv_to_full_win32_path(cmdLine, buf); > > + cygwin_conv_path(CCP_POSIX_TO_WIN_A, cmdLine, buf, sizeof(buf)); > > Buildfarm member brown_bat didn't like this. Seeing that that's the > *only* active cygwin buildfarm member, that's not a good percentage. Hmmm, but avoiding deprecated APIs would be good on the lastest cygwin. How about checking the version with #ifdef? #ifdef __CYGWIN__ /* need to convert to windows path */ +#if CYGWIN_VERSION_DLL_MAJOR >= 1007 cygwin_conv_path(CCP_POSIX_TO_WIN_A, cmdLine, buf, sizeof(buf)); +#else + cygwin_conv_to_full_win32_path(cmdLine, buf); +#endif strcpy(cmdLine, buf);#endif Regards, --- Takahiro Itagaki NTT Open Source Software Center
On Tue, Apr 6, 2010 at 07:29, Takahiro Itagaki <itagaki.takahiro@oss.ntt.co.jp> wrote: > > Tom Lane <tgl@sss.pgh.pa.us> wrote: > >> > - cygwin_conv_to_full_win32_path(cmdLine, buf); >> > + cygwin_conv_path(CCP_POSIX_TO_WIN_A, cmdLine, buf, sizeof(buf)); >> >> Buildfarm member brown_bat didn't like this. Seeing that that's the >> *only* active cygwin buildfarm member, that's not a good percentage. > > Hmmm, but avoiding deprecated APIs would be good on the lastest cygwin. > How about checking the version with #ifdef? > > #ifdef __CYGWIN__ > /* need to convert to windows path */ > +#if CYGWIN_VERSION_DLL_MAJOR >= 1007 > cygwin_conv_path(CCP_POSIX_TO_WIN_A, cmdLine, buf, sizeof(buf)); > +#else > + cygwin_conv_to_full_win32_path(cmdLine, buf); > +#endif > strcpy(cmdLine, buf); > #endif That seems like the way to do it. Or if it's used in many places, use a #define from one to the other - we don't want those #ifdef's all over the place. Seems cygwin may have deprecated that API a bit early :-), but there's nothing we can do about that. If it's deprecated, they'll eventually delete it... -- Magnus HaganderMe: http://www.hagander.net/Work: http://www.redpill-linpro.com/