Compile fail, alpha5 & gcc 4.3.3 in elog.c

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(at)agliodbs(dot)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(at)agliodbs(dot)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(at)agliodbs(dot)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(at)agliodbs(dot)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(at)kaltenbrunner(dot)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(at)agliodbs(dot)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.

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.

/Magnus

On Mar 29, 2010 6:14 PM, "Peter Eisentraut" <peter_e(at)gmx(dot)net> wrote:

On sön, 2010-03-28 at 19:22 -0400, Robert Haas wrote:
> On Sun, Mar 28, 2010 at 4:40 PM, Josh Berkus...
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.

--
Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
To make changes to your sub...

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(at)agliodbs(dot)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(at)gmail(dot)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(at)hagander(dot)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(at)agliodbs(dot)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(at)pgadmin(dot)org> wrote:
> On Wed, Mar 31, 2010 at 6:46 PM, Josh Berkus <josh(at)agliodbs(dot)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(at)gmail(dot)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(at)agliodbs(dot)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(at)pgadmin(dot)org> wrote:
> On Wed, Mar 31, 2010 at 7:52 PM, Robert Haas <robertmhaas(at)gmail(dot)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(at)gmail(dot)com> wrote:
> On Wed, Mar 31, 2010 at 3:29 PM, Dave Page <dpage(at)pgadmin(dot)org> wrote:
>> On Wed, Mar 31, 2010 at 7:52 PM, Robert Haas <robertmhaas(at)gmail(dot)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(at)gmail(dot)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(at)pgadmin(dot)org> wrote:
> On Thu, Apr 1, 2010 at 5:24 AM, Robert Haas <robertmhaas(at)gmail(dot)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(at)agliodbs(dot)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(at)agliodbs(dot)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(at)agliodbs(dot)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 (declared
at /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(at)agliodbs(dot)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(at)gmail(dot)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(at)gmx(dot)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
>

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(at)agliodbs(dot)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 12:34 PM, Kevin Grittner
<Kevin(dot)Grittner(at)wicourts(dot)gov> wrote:
> Josh Berkus <josh(at)agliodbs(dot)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 fre, 2010-04-02 at 14:44 -0400, Robert Haas wrote:
> On Apr 2, 2010, at 12:34 PM, Kevin Grittner
> <Kevin(dot)Grittner(at)wicourts(dot)gov> wrote:
> > Josh Berkus <josh(at)agliodbs(dot)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(at)gmx(dot)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

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 6:07 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Peter Eisentraut <peter_e(at)gmx(dot)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

On Fri, Apr 2, 2010 at 2:44 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Apr 2, 2010, at 12:34 PM, Kevin Grittner
> <Kevin(dot)Grittner(at)wicourts(dot)gov> wrote:
>> Josh Berkus <josh(at)agliodbs(dot)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(dot)takahiro(at)oss(dot)ntt(dot)co(dot)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

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(at)2ndQuadrant(dot)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(at)sss(dot)pgh(dot)pa(dot)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(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp> wrote:
>
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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 Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/