RE: [HACKERS] Packaging 7.1.1
On Thu, 3 May 2001, Rachit Siamwalla wrote: > 1. `pidof` should be `pidof -s` (2 instances) > 2. restart) should be stop; sleep x; start > ideally, stop should actually wait till postgres fully stops. The sleep is > just a temporary fix. > Perhaps a naive question, but why not use the pg_ctl for starting and stopping? It has a -w option to have it wait for the stop/start/restart to complete. -rocco ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Non-standard feature request
On Fri, 14 Jun 2002, Mike Mascari wrote: > That is what I want to do, except by extending the grammar. I must admit > to actually being surprised that a TEMP table created inside a > transaction lived after the transaction completed. That's when I looked > at the standard and saw that PostgreSQL's implementation was correct. I > would think for most people session-long temp tables are more the > exception than the rule. But I guess SQL92 doesn't think so. Regardless, > a couple of other people have shown some interest in the idea. I'll post > it to general as well as Tom suggests... > Actually, we needed to use temp tables that live beyond the transaction, because there are no session variables in postgres. So I did an implementation that used temp tables instead. Having the temp table not live for the life of the session would be a big problem for me. -rocco ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] [COMMITTERS] pgsql: another try at keeping AIX/ppc happy on cube test.
I think this will cause breakage for other people. Right now I think the order is unique to AIX for some reason. Recent buildfarm run of gazelle should have matched the -0 variant (cube_1.out), but did not. Also, what is worrisome is that there is an ORDER BY on the result set that is failing on AIX, so I think there might be a deeper problem lurking here. Thanks, -rocco > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Andrew Dunstan > Sent: Thursday, July 27, 2006 2:39 PM > To: pgsql-committers@postgresql.org > Subject: [COMMITTERS] pgsql: another try at keeping AIX/ppc > happy on cube test. > > > Log Message: > --- > another try at keeping AIX/ppc happy on cube test. > > Modified Files: > -- > pgsql/contrib/cube/expected: > cube_1.out (r1.4 -> r1.5) > > (http://developer.postgresql.org/cvsweb.cgi/pgsql/contrib/cube /expected/cube_1.out.diff?r1=1.4&r2=1.5) ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[HACKERS] Buildfarm failure - asp
Had a buildfarm failure on asp (AIX/gcc), because of an extra space in the Makefile.regress for ecpg. Attached is a patch to allow a clean compile. -rocco ecpg-test-Makefile.patch Description: ecpg-test-Makefile.patch ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] ecpg test suite
> From: Joachim Wieland [mailto:[EMAIL PROTECTED] > Sent: Thursday, August 03, 2006 11:23 AM > To: Tom Lane; Michael Meskes; Rocco Altier; PostgreSQL Hacker > Subject: Re: [HACKERS] ecpg test suite > > > On Thu, Aug 03, 2006 at 04:54:35PM +0200, Michael Meskes wrote: > > > diff: `-3' option is obsolete; omit it > > > diff: Try `diff --help' for more information. > > > Strange, works well on my Linux system. However, I tried > correcting the > > option but I'm unsure if it works for you now since both > versions worked > > for me. > > This got introduced by Rocco's Makefile patch, it worked for me, so I > thought it's fine. Rocco, your AIX box will work with only > diff -c as well, > won't it? > I had used -c to replace the -u. The '-c3' does not work on my machine, but '-C3' does, so I think we should go with that. Thanks, -rocco ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] ecpg test suite
Here is my updated regression.diff. Like Tom, I was running with my server configured to run on 5678, instead of 5432, so it seems like the test is using a wrong port number somewhere. I changed my local pg_regress.sh to use -C3 on the diffs, until we figure out what the final form of that will be. BTW, I do have --enable-integer-datetimes configured for this machine, which might explain the timestamp differences. Thanks, -rocco > -Original Message- > From: Michael Meskes [mailto:[EMAIL PROTECTED] > Sent: Thursday, August 03, 2006 9:12 AM > To: Rocco Altier > Cc: Michael Meskes; PostgreSQL Hacker; [EMAIL PROTECTED] > Subject: Re: [HACKERS] ecpg test suite > > > Hi, > > I just committed some changes by Joachim that should reduce > the problems > and the differences by a large margin. Could you please rerun the test > and send us the regression.diff? Thanks a lot in advance. > > Michael > -- > Michael Meskes > Email: Michael at Fam-Meskes dot De, Michael at Meskes dot > (De|Com|Net|Org) > ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] > Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! > regression.diff Description: regression.diff ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] TODO Request
> From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Hannu Krosing > > Ühel kenal päeval, T, 2006-08-29 kell 22:12, kirjutas Joshua D. Drake: > > >> Auto creations of partitions > > > > This would be something like: > > > > create table foo () partition by ... > > from the referenced MySQL manual entry > > CREATE TABLE members ( > ... > joined DATE NOT NULL > ) > PARTITION BY KEY(joined) > PARTITIONS 6; > > Do you have any idea how this should work ? > > What date range should go into which partition ? > Since we don't have any knowledge about the date ranges in question, and the fact that they could change over time, I think the only stable way to handle this scenario would be to use a hash function which had 6 buckets (something like 'date % 6' could work). I do see an issue, if someone wanted to change the number of partitions in use, since it would have to rehash the table, and move data around. I don't see any other way to handle this, but I might not be thinking hard enough. -rocco ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
[HACKERS] BF failure - kookaburra - ecpg
One of the new ecpg tests for comments fails to compile the resulting .c file, because my vendor C compiler doesn't like '//' style comments, when running in C mode. Specifically its line 12 of comment.pgc: // we also understand this style It seems like ecpg should translate the comment from '//' to '/* */' style, for the output .c file. Thanks, -rocco ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: AIX shared libraries (was Re: [PATCHES] [HACKERS] Fix linking of OpenLDAP libraries)
> Tom Lane wrote: > > Is it > > possible that the rules have changed across AIX versions, > > and that the code in there now is needful for older versions? > > I don't think that this behaviour has changed. I remember it from > AIX 4.3.2. > AIX 4.3 is the first version to support the -brtl. The current code is in place to mimic the behaviour of dlopen, etc, on the older platforms. I think we are at a point that we can stop maintaining AIX older than 4.3 if we want. -rocco ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [PATCHES] [HACKERS] Fix linking of OpenLDAP libraries
The patch did not work for me :-( My buildfarm members failed in local testing to execute the install-check, because initdb failed to find libpq.so. Make check did succeed, so I think there is a possibility of getting it working, but it won't be as simple as adding -brtl to the template. I was also getting duplicate symbols in the link, that I wasn't before either. I don't have time right now to work through all the issues, but wanted to give feedback that the patch isn't quite this simple. Thanks, -rocco > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Albe Laurenz > Sent: Tuesday, September 12, 2006 9:01 AM > To: Tom Lane *EXTERN* > Cc: pgsql-hackers@postgresql.org > Subject: Re: [PATCHES] [HACKERS] Fix linking of OpenLDAP libraries > > > Tom Lane wrote: > >> In our case, we have libpq.a and libpq.so in the same directory, > >> so unless you link with -brtl you will get a static link > >> (because libpq.a is a static library). > > > > I wonder whether we ought to suppress building (or at least > installing) > > our .a libraries at all on AIX. Adding -btrl to LDFLAGS would help > > within the context of our own build, but external clients that link > > to libpq without saying that are going to get undesirable results. > > > > I think there's a reasonable argument that by installing a .a file > that > > isn't a shared library, we are violating the platform's conventions. > > The natural way in AIX would be: > - Create libpq.so > - Create libpq.a by 'rm -f libpq.a; ar -rc libpq.a libpq.so' > - Install only libpq.a > > For a static build on AIX, you have to specify all the libraries and > give the linker -bstatic and -bI:/lib/syscalls.exp > > >> Should -brtl be added to src/template/aix? > > > > Sounds that way, but that'll only help for psql and other > stuff built > > within our build. Could you try this against CVS tip: > > > > * add -brtl to LDFLAGS in the template > > * Remove the AIX-specific hack on $(libpq) at lines 349-354 of > > src/Makefile.global.in > > * see if it configures and builds > > I have done that (see the attached patch) and it works fine. > I don't have the native AIX C compiler, so I could only test > it with gcc. > > I have taken the liberty to modify the static link line > in Makefile.global.in to contain the LDAP libraries, I hope > that's appropriate. > > Yours, > Laurenz Albe > ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [PATCHES] [HACKERS] Linking on AIX (Was: Fix linking of OpenLDAP libraries )
> I suspect that up to now the buildfarm had a static build of > PostgreSQL. What is the output of 'ldd initdb' when it builds > and runs correctly? > > Is libpq.so in a non-standard directory? If yes, one either > has to export LIBPATH in the environment or link with > -L/location/of/libpq for the executable to find it > (similar to RPATH in Linux). > Here is the working one: initdb needs: /usr/lib/libc.a(shr.o) /unix /usr/lib/libcrypt.a(shr.o) Here is the broken one: initdb needs: ../../../src/interfaces/libpq/libpq.so /usr/lib/libc.a(shr.o) /usr/lib/librtl.a(shr.o) /unix /usr/lib/libcrypt.a(shr.o) When run it shows: exec(): 0509-036 Cannot load program initdb because of the following errors: 0509-150 Dependent module libpq.so could not be loaded. 0509-022 Cannot load module libpq.so. 0509-026 System error: A file or directory in the path name does not exist. ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] [HACKERS] Linking on AIX (Was: Fix linking of OpenLDAP libraries )
> From: Tom Lane [mailto:[EMAIL PROTECTED] > "Albe Laurenz" <[EMAIL PROTECTED]> writes: > > Up to now you have built against the static libpq.a > > I didn't add the right -blibpath to this patch that > > failed for you - the broken initdb is dynamically linked > > but does not know where to look for its shared library. > > > The patch I just submitted to pgsql-patches should take > > care of that. It makes the executables look in --libdir. > > Mmm ... what of "make check"'s temporary installation? We need > to have the executables search in the temporary install's libdir, > *before* looking in the configured --libdir (which could easily > contain an incompatible back-version libpq ...) > > pg_regress normally tries to handle this by setting LD_LIBRARY_PATH > ... does AIX use that or a similar symbol? > The "make check" was successful in my previous testing of the last patch, so it appears that AIX was paying attention to LD_LIBRARY_PATH. I am testing the new version of the patch now, so will report back shortly. Thanks, -rocco ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] [HACKERS] Linking on AIX (Was: Fix linking of OpenLDAP libraries )
> > From: Tom Lane [mailto:[EMAIL PROTECTED] > > Mmm ... what of "make check"'s temporary installation? We need > > to have the executables search in the temporary install's libdir, > > *before* looking in the configured --libdir (which could easily > > contain an incompatible back-version libpq ...) > > > > pg_regress normally tries to handle this by setting LD_LIBRARY_PATH > > ... does AIX use that or a similar symbol? > > > The "make check" was successful in my previous testing of the last > patch, so it appears that AIX was paying attention to LD_LIBRARY_PATH. > > I am testing the new version of the patch now, so will report back > shortly. > From testing the new patch, it did not work for the regression tests in the buildfarm. Not sure why it did work before. Anyhow, I have updated the patch to set LIBPATH (AIX's version of LD_LIBRARY_PATH), in pg_regress and ecpg's pg_regress. I have tested this with default config options (enable-shared, enable-rpath). I am starting to test the other methods as well, but wanted to get this out first. -rocco ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [PATCHES] [HACKERS] Linking on AIX (Was: Fix linking of OpenLDAP libraries )
With the patch attached this time... -rocco > -Original Message- > From: Rocco Altier > Sent: Friday, September 15, 2006 2:04 PM > To: Rocco Altier; 'Tom Lane'; 'Albe Laurenz' > Cc: 'pgsql-hackers@postgresql.org' > Subject: RE: [PATCHES] [HACKERS] Linking on AIX (Was: Fix > linking of OpenLDAP libraries ) > > > > > From: Tom Lane [mailto:[EMAIL PROTECTED] > > > Mmm ... what of "make check"'s temporary installation? We need > > > to have the executables search in the temporary install's libdir, > > > *before* looking in the configured --libdir (which could easily > > > contain an incompatible back-version libpq ...) > > > > > > pg_regress normally tries to handle this by setting > LD_LIBRARY_PATH > > > ... does AIX use that or a similar symbol? > > > > > The "make check" was successful in my previous testing of the last > > patch, so it appears that AIX was paying attention to > LD_LIBRARY_PATH. > > > > I am testing the new version of the patch now, so will report back > > shortly. > > > From testing the new patch, it did not work for the > regression tests in the buildfarm. > Not sure why it did work before. > > Anyhow, I have updated the patch to set LIBPATH (AIX's > version of LD_LIBRARY_PATH), in pg_regress and ecpg's pg_regress. > > I have tested this with default config options > (enable-shared, enable-rpath). I am starting to test the > other methods as well, but wanted to get this out first. > > -rocco > aix.link.regression.patch Description: aix.link.regression.patch ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] 8.2 beta blockers
> -Original Message- > From: [EMAIL PROTECTED] > Yeah, I know, which is why I don't find it absolutely critical that > this make it to beta1. But one of the concerns mentioned in > the thread > is that the changes might break things for older AIX versions. If we > get it into beta1, we have a better chance of finding out > before release > whether there are any issues with AIX versions that aren't represented > in buildfarm. > As a backdoor, we can leave in the code to compile static for the old versions, but I am not sure its worth it. As a side note, I tried to build CVS on an AIX 4.1 box, and it already has issues. The TOC is too large for ld, amongst others. I had tried to get our older box onto the buildfarm, but the version of Perl on that box was too ancient to run the buildfarm code, and I didn't think people would care too much about it missing, since its such an old version anyway. Then I discovered the issues with trying to build by hand, and gave up at that point. I think we should make our cut-off version as 4.3. This is the first to support run time linking, so the changes we are talking about for today will work on that version. It came out in October 97 and was EOL'd Dec 2001. If someone really wants to run on something older than a 9 year old OS, that was EOL'd almost 5 years ago. I think they should do so at their peril, and its not up to us to go out of our way to support them. I don't think we will be making an AIX uesrs sad by adding support for dynamic linking, but breaking old versions of the OS. Thanks, -rocco ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[HACKERS] Buildfarm & cvsignore files
I noticed that the build farm is only looking for the cvs-ignore'd files for a vpath build. Attached is a patch that will stop at the CVS stage if there are any cvs-ignore'd files in the clean repository. Its not triggered by a from-source build, only what should have been a clean check out. Thanks, -rocco > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Andrew Dunstan > Sent: Sunday, September 03, 2006 11:45 AM > To: Tom Lane > Cc: Chris Browne; pgsql-hackers@postgresql.org > Subject: Re: [HACKERS] [COMMITTERS] pgsql: Second try > committing the path > > > > > Andrew Dunstan wrote: > > Tom Lane wrote: > >> > >> The buildfarm script is supposed to complain about > unexpected files in > >> the repository --- I wonder if it is fooled by the > .cvsignore entries > >> for these files? > >> > > > > Yes, we do. A patch made in July 2005 has this comment: > > > > "ignore files listed in cvsignore files - this will stop > inappropriate > > triggering of vpath builds." > > > > > > Perhaps I should only do that for vpath builds. Or perhaps I should > > even remove them at the end of a build, since we don't > expect any of > > those files in a clean repo, do we? > > > > Also, in case anyone has not got the message yet: Don't > ever build by > > hand in the buildfarm repo. Ever. I mean it. Use a copy. > > > > > > I have just committed a patch that removes the cvsignore trap. This > should be safe as we now remove them at the end of a > buildfarm vpath run. > > cheers > > andrew > > ---(end of > broadcast)--- > TIP 5: don't forget to increase your free space map settings > pgbf-cvsignore.patch Description: pgbf-cvsignore.patch ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Win XP SP2 SMP locking (8.1.4)
Didn't the stats communication process get redone for 8.2? Or atleast some time-out related stuff. Since the problem seems to be related to stats_row_level being on, I wonder if the problem might be in that sub-system. I am guessing that vacuum is pushing some more stats through, which might explain how that allows it to unfreeze. -rocco > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Magnus Hagander > Sent: Friday, October 06, 2006 6:00 AM > To: Oleg Bartunov > Cc: Pgsql Hackers > Subject: Re: [HACKERS] Win XP SP2 SMP locking (8.1.4) > > > > >> I'm looking into strange locking, which happens on WinXP SP2 SMP > > >> machine running 8.1.4 with stats_row_level=on. This is the only > > >> combination (# of cpu and stats_row_level) which has problem - > > SMP + > > >> stats_row_level. > > >> > > >> The same test runs fine with one cpu (restarted machine with > > >> /numproc=1) disregarding to stats_row_level option. > > >> > > >> Customer's application loads data into database and sometimes > > process > > >> stopped, no cpu, no io activity. PgAdmin shows current query is > > >> 'COMMIT'. > > >> I tried to attach gdb to postgres and client processes, but > > backtrace > > >> looks useless (see below). Running vacuum analyze of this > > database in > > >> separate process cause loading process to continue ! Weird. > > >> > > >> It's interesting, that there is no problem with 8.2beta1 in all > > >> combinations ! Any idea what changes from 8.1.4 to > > >> 8.2beta1 could affect the problem ? > > > > > > There is a new implementations of semaphores in 8.2. That could > > > possibly be it. > > > > I backported them to REL8_1_STABLE but it doesn't helped. Any other > > idea what to do, or how to debug the situation ? > > Unfortunatly, the debugger support for mingw is absolutely > horrible. But > you can try process explorer from www.sysinternals.com and > see if it'll > give you a decent backtrace. Sometimes it works when others don't. > Either that, or try the Visual Studio or Windows debuggers, they can > usually at least show you if it's stuck waiting on something in the > kernel. > > //Magnus > > ---(end of > broadcast)--- > TIP 4: Have you searched our list archives? > http://archives.postgresql.org ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] [COMMITTERS] pgsql: Work around reported problem that AIX's getaddrinfo() doesn't
This change has broken my AIX 5.2 buildfarm machine (asp/kookaburra), but doesn't seem to break the 5.3 member (grebe). It appears to have problems with stats being off now? What can I do to help debug the situation? -rocco > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Tom Lane > Sent: Thursday, October 19, 2006 1:27 PM > To: pgsql-committers@postgresql.org > Subject: [COMMITTERS] pgsql: Work around reported problem > that AIX's getaddrinfo() doesn't > > > Log Message: > --- > Work around reported problem that AIX's getaddrinfo() doesn't > seem to zero > sin_port in the returned IP address struct when servname is > NULL. This has > been observed to cause failure to bind the stats collection > socket, and > could perhaps cause other issues too. Per reports from Brad Nicholson > and Chris Browne. > > Modified Files: > -- > pgsql/src/backend/libpq: > ip.c (r1.36 -> r1.37) > > (http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/ libpq/ip.c.diff?r1=1.36&r2=1.37) ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] IPv6 patch
Another idea is to have the -i take an optional argument. Something where -i means bind to both v4 and v6, and -i4 means to only v4, and -i6 to only v6. I am guessing that most people will want to bind to both when they just specify -i, which is what is usually suggested when they want to get the box up and running. If they want do something fancy, like only bind to v6, then they will read the docs and see that they can do that with something like -i6. -rocco On Tue, 7 Jan 2003, Bruce Momjian wrote: > > You mean ship with only IPv4 enabled, but not IPv6. (Of course, both > are enabled in the binary.) But then what does -i do? We currently > tell people to use -i. Do we need another postgresql.conf option that > says, "If tcpip_socket is enabled, enable IPv6 too"? But that doesn't > work if you want _only_ IPv6. > > The big problem is it doesn't mix with tcpip_socket and -i very well. I > am not saying I have a better idea, I am just looking for something > clearer. Perhaps we need a separate flag/postgresql.conf option for > IPv6 so they can be controlled separately. Have we figured out how to > listen on IPv6 only? > > --- > > Nigel Kukard wrote: > > > > IPV4 only should be shipped by default, but disabled as it is at present. > > > > > > On Tue, 7 Jan 2003, Bruce Momjian wrote: > > > > > > > > OK, what do we ship as a default? > > > > > > --- > > > > > > Nigel Kukard wrote: > > > > Sorry i'm not subscribed to hackers, guess i must get soon! > > > > > > > > > > > > Anyway what i think should happen is follows, if in the configuration file > > > > we specify that it must bind to both ie. tcpip_socket = true, the server > > > > should check if first its compiled to support ipv6 (or skip this if we use > > > > #ifdef's) and secondly bind to what WE tell it to. If we specify TRUE it > > > > must try to bind to both. Ok thats the first case, the second case is if > > > > we specify ipv4, ie. tcpip_socket = 4. This should ONLY bind ipv4, not ipv6 > > > > and if there is no ipv4 support on the box it should fail, not fallback. > > > > And finally the third case, if we specify tcpip_socket = 6, we should > > > > again ONLY bind to ipv6, if there is no ipv6 support compiled, or if we > > > > cannot bind to the specific interface we should fail. > > > > > > > > Thats my opinion ;) > > > > > > > > > > > > -Nigel > > > > > > > > > > > > > > > > On 6 Jan 2003, Robert Treat wrote: > > > > > > > > > On Mon, 2003-01-06 at 16:40, Bruce Momjian wrote: > > > > > > Peter Eisentraut wrote: > > > > > > > Bruce Momjian writes: > > > > > > The issue is that right now, there isn't any special IPv6 enabling, > > > > > > except for lines in pg_hba.conf. I think it is fine to add some > > > > > > enabling, but we then have an additional user interface issue. One idea > > > > > > I had was to change tcpip_socket from true/false to true/false/4/6 so > > > > > > you can specify if you want none(false)/4/6/both(true). The original > > > > > > patch author wants this functionality too, so there clearly is a need > > > > > > for this. This doesn't play nice with the -i flag, however. > > > > > > > > > > > > > > > > Would there a downside to specifying both (enabling ipv6) on a machine > > > > > that doesn't support it? If not I'd suggest making -i equivalent to > > > > > tcp_ip_socket = true. I don't think it's too much to ask people to use > > > > > the preferred method to obtain maximum functionality. > > > > > > > > > > > Also, keep in mine my BSD/OS has libraries to support IPv6, but IPv6 > > > > > > isn't enabled in the kernel, so there is a case where HAVE_IPV6 is true, > > > > > > but when run, opening an IPV6 server fails and I fall back to IPv4 --- > > > > > > just throwing that out as a data point. What would be our default as > > > > > > shipped? > > > > > > > > > > If there is no downside to allowing both, probably both. If there is a > > > > > downside then ipv4, since it much more likely to be the default on OS's > > > > > for the next release or two. > > > > > > > > > > Robert Treat > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > Nigel Kukard (Chief Executive Officer) > > > > Lando Technologies Africa (Pty) Ltd > > > > [EMAIL PROTECTED] www.lando.co.za > > > > Tel: 083 399 5822 Fax: 086 1100036 > > > > Hoheisen Park Bellville, Cape Town > > > > National Internet Service Provider > > > > > > > > > > > > The best language to use is the language that was designed for > > > > what you want to use it for - 1997 > > > > > > > > > > > > = > > > > > > > > Disclaimer > > > > -- > > > > The contents of this message and any attachments are intended > > > > solely for the addressee's use and may be l
Re: [HACKERS] regressin failure on latest CVS
This patch fixes the interval regression on my AIX box (kookaburra) by only doing integer math on the interval, instead of float/double math. I think this is the correct way to handle this, since it's an integer data type. I don't know if it will fix Olivier's problem, since I wasn't able to reproduce it. Thanks, -rocco > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Bruce Momjian > Sent: Friday, July 22, 2005 10:41 AM > To: Michael Glaesemann > Cc: ohp@pyrenet.fr; pgsql-hackers@postgresql.org > Subject: Re: [HACKERS] regressin failure on latest CVS > > > Michael Glaesemann wrote: > > > > On Jul 22, 2005, at 6:28 PM, ohp@pyrenet.fr wrote: > > > > > I tried the latest cvs this morning (07/22 11:00 CET) > > > and interval test fails. > > > Here's the regression.diffs. > > > > > > > > *** ./expected/interval.outFri Jul 22 10:32:21 2005 > > > --- ./results/interval.outFri Jul 22 11:07:54 2005 > > > *** > > > *** 217,224 > > > -- updating pg_aggregate.agginitval > > > select avg(f1) from interval_tbl; > > > avg > > > ! - > > > ! @ 4 years 1 mon 10 days 4 hours 18 mins 23 secs > > > (1 row) > > > > > > -- test long interval input > > > --- 217,224 > > > -- updating pg_aggregate.agginitval > > > select avg(f1) from interval_tbl; > > > avg > > > ! > > > ! @ 4 years 1 mon 9 days 4 hours 18 mins 23 secs > > > (1 row) > > > > > > -- test long interval input > > > > Could you provide platform information? Did you build with > --enable- > > integer-datetimes? Looking at the buildfarm, kookaburra > (AIX 5.2) is > > also failing the interval test at the same point, but the > result is > > different. > > Interesting. I don't see the error with our without > --enable-integer-datetimes. I even tried changing my > timezone to Paris > time and still could not reproduce the failure. > > On the AIX problem below, we are going to get rounding issues. > > -- > - > > > > http://pgbuildfarm.org/cgi-bin/show_history.pl?nm=kookaburra&br=HEAD > > > > == pgsql.36852/src/test/regress/regression.diffs > > === > > *** ./expected/interval.out Fri Jul 22 01:25:05 2005 > > --- ./results/interval.out Fri Jul 22 01:34:20 2005 > > *** > > *** 217,224 > >-- updating pg_aggregate.agginitval > >select avg(f1) from interval_tbl; > > avg > > ! - > > ! @ 4 years 1 mon 10 days 4 hours 18 mins 23 secs > >(1 row) > > > >-- test long interval input > > --- 217,224 > >-- updating pg_aggregate.agginitval > >select avg(f1) from interval_tbl; > >avg > > ! > > ! @ 4 years 1 mon 10 days 4 hours 18 mins 22.99 secs > >(1 row) > > > > > > Michael Glaesemann > > grzm myrealbox com > > > > > > > > ---(end of > broadcast)--- > > TIP 1: if posting/reading through Usenet, please send an appropriate > >subscribe-nomail command to [EMAIL PROTECTED] > so that your > >message can get through to the mailing list cleanly > > > > -- > Bruce Momjian| http://candle.pha.pa.us > pgman@candle.pha.pa.us | (610) 359-1001 > + If your life is a hard drive, | 13 Roberts Road > + Christ can be your backup.| Newtown Square, > Pennsylvania 19073 > > ---(end of > broadcast)--- > TIP 4: Have you searched our list archives? > http://archives.postgresql.org timestamp.patch Description: timestamp.patch ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] regressin failure on latest CVS
This still does not fix the problem. I had done my patch to try to mimic the way 8.0 had handled the math with the remainders, but to carry it over another bucket (day). The problem that I see is that we are taking day_remainder and multiplying by USECS_PER_DAY. Which is a double * int64, thus there is the precision loss there. I think initial division by the factor can't be helped, but repeatedly doing more floating point math on with it is causing the rounding error. Thanks, -rocco > -Original Message- > From: Bruce Momjian [mailto:[EMAIL PROTECTED] > Sent: Saturday, July 23, 2005 10:54 AM > To: Rocco Altier > Cc: Michael Glaesemann; pgsql-patches@postgresql.org; > pgsql-hackers@postgresql.org; ohp@pyrenet.fr > Subject: Re: [HACKERS] regressin failure on latest CVS > > > Rocco Altier wrote: > > This patch fixes the interval regression on my AIX box > (kookaburra) by > > only doing integer math on the interval, instead of > float/double math. > > > > I think this is the correct way to handle this, since it's > an integer > > data type. > > > > I don't know if it will fix Olivier's problem, since I > wasn't able to > > reproduce it. > > > > I have changed the way I compute the remainder values --- instead of > using multiplication, I use division and then subtraction. > This should > fix your rounding problem. Looking at your fix, I don't see > how adding > USECS changes things because the factor is already a float, > but I think > the problem was more the way I was computing the remainders. > > Patch attached --- let me know if it does not fix your problem. > > -- ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] [COMMITTERS] pgsql: Add GUC variables to control keep-alive times for idle, interval,
This broke the build on AIX. AIX does not have SOL_TCP as a defined symbol in any of the system header files. -rocco > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Bruce Momjian > Sent: Saturday, July 30, 2005 11:17 AM > To: pgsql-committers@postgresql.org > Subject: [COMMITTERS] pgsql: Add GUC variables to control > keep-alive times for idle, interval, > > > Log Message: > --- > Add GUC variables to control keep-alive times for idle, interval, and > count. > > Oliver Jowett > > Modified Files: > -- > pgsql/doc/src/sgml: > runtime.sgml (r1.339 -> r1.340) > > (http://developer.postgresql.org/cvsweb.cgi/pgsql/doc/src/sgml /runtime.sgml.diff?r1=1.339&r2=1.340) pgsql/src/backend/libpq: pqcomm.c (r1.176 -> r1.177) (http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/libpq/pqco mm.c.diff?r1=1.176&r2=1.177) pgsql/src/backend/utils/misc: guc.c (r1.279 -> r1.280) (http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/utils/misc /guc.c.diff?r1=1.279&r2=1.280) postgresql.conf.sample (r1.154 -> r1.155) (http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/utils/misc /postgresql.conf.sample.diff?r1=1.154&r2=1.155) pgsql/src/bin/psql: tab-complete.c (r1.135 -> r1.136) (http://developer.postgresql.org/cvsweb.cgi/pgsql/src/bin/psql/tab-compl ete.c.diff?r1=1.135&r2=1.136) pgsql/src/include/libpq: libpq-be.h (r1.49 -> r1.50) (http://developer.postgresql.org/cvsweb.cgi/pgsql/src/include/libpq/libp q-be.h.diff?r1=1.49&r2=1.50) pgsql/src/include/utils: guc.h (r1.61 -> r1.62) (http://developer.postgresql.org/cvsweb.cgi/pgsql/src/include/utils/guc. h.diff?r1=1.61&r2=1.62) ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] Cygwin - make check broken
It looks like when we changed regress/GNUmakefile to pull rules from Makefile.shlib, cygwin got broken in the process. The problem is that regess.dll ends up being a symlink back to itself, because we do a: $(NAME)$(DLSUFFIX): $(shlib) rm -f $(NAME)$(DLSUFFIX) $(LN_S) $(shlib) $(NAME)$(DLSUFFIX) And from Makefile.shlib (for cygwin) ifeq ($(PORTNAME), cygwin) shlib = $(NAME)$(DLSUFFIX) Thus regress.dll gets unhappy :-( I don't know enough about the rest of the way the cygwin port is put together, but it seems that the other platforms all have shlib=lib$(NAME)... -rocco ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Intermittent stats test failures on buildfarm
Also, kookaburra (AIX) has a problem with the stats test as well. What is most puzzling to me is that it only happens with cc (not gcc). And I can only get it to happen when running a cronjob for the buildfarm. If I run it interactively, the stats collector will run fine, or if I run the build script from the command line. The environment between cron and from command line are not significantly different, so I am at a bit of loss as to the reason why. Any thoughts? -rocco > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Tom Lane > Sent: Tuesday, August 30, 2005 12:31 AM > To: pgsql-hackers@postgreSQL.org > Subject: [HACKERS] Intermittent stats test failures on buildfarm > > > I just spent a tedious hour digging through the buildfarm results > to see what I could learn about the intermittent failures we're seeing > in the stats regression test, such as here: > http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=ferret&dt=20 > 05-05-29%2018:25:09 > This is seen in both Check and InstallCheck steps. A variant > pathology > is seen here: > http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=gerbil&dt=20 > 05-07-22%2007:58:01 > Notice that only the heap stats columns are wrong in this > case, not the > index stats. I think that this variant behavior may have > been fixed by > this patch: > > 2005-07-23 20:33 tgl > > * src/backend/postmaster/pgstat.c: Fix some failures to > initialize > table entries induced by recent autovacuum integration. > Not clear > this explains recent stats problems, but it's definitely wrong. > > but it's not certain since nobody traced through the code to exhibit > why those uninitialized table entries would have led to this > particular > visible symptom. But with no occurrences of that behavior since the > patch went in, I suspect it's fixed. > > What we are left with turns out to be multiple occurrences of > the first > pathology on exactly three buildfarm members: > > ferret Cygwin > kuduSolaris 9, x86 > dragonfly Solaris 9, x86 > > There are no occurrences of the failure on the native-Windows > machines, > nor on buzzard (Solaris 10, SPARC), nor on gerbil (Solaris 9, SPARC) > (though gerbil has one old occurrence of the second > pathology, so maybe > that observation should be taken with a grain of salt). And none > whatever on any other buildfarm member. > > The same three machines are showing the failure in the 8.0 > branch, too, > so it's not a recently-introduced issue. > > And one thing more: kudu and dragonfly are actually the same machine, > same OS, different compilers. > > So what to make of this? Dunno, but it is clearly a very > platform-specific behavior. Anyone see a connection between Cygwin > and Solaris? > > regards, tom lane > > ---(end of > broadcast)--- > TIP 3: Have you checked our extensive FAQ? > http://www.postgresql.org/docs/faq ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] [COMMITTERS] pgsql: Mention "table" in "violates foreign key constraint" message that
Does the regression test need to be updated as well for this? I am seeing a failure on my buildfarm machines. -rocco > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Bruce Momjian > Sent: Wednesday, December 28, 2005 11:47 AM > To: pgsql-committers@postgresql.org > Subject: [COMMITTERS] pgsql: Mention "table" in "violates > foreign key constraint" message that > > > Log Message: > --- > Mention "table" in "violates foreign key constraint" message that was > lacking it. Perhaps it was suppressed because of line length > considerations, but "table" should appear. > > Modified Files: > -- > pgsql/src/backend/utils/adt: > ri_triggers.c (r1.83 -> r1.84) > > (http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/ utils/adt/ri_triggers.c.diff?r1=1.83&r2=1.84) ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [pgsql-advocacy] Not 7.5, but 8.0 ?
On Tue, 18 Nov 2003, ow wrote: > Have *never* seen ppl running Oracle or Sybase on Windows. I can't speak for Oracle, but Sybase on Windows is definitely a real thing. If you have to deal with developing for their iAnywhere product (a remote replication solution for PocketPC applications), Windows is the first class citizen for the database and Unix is definitely second class (can attest to that from first hand experience). We had trouble convincing them that we wanted to run with Postgres as the data repository under Unix. A native win32 port would have helped us out. -rocco ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Some platform-specific MemSet research
I wanted to chime in that I also see this speedup from using XLC 6.0 (IBM's cc), even in 32bit mode. I have tested on AIX 5.2 and 5.1. I think this would be good to include in the regular release. Not sure how many people are running older versions of AIX that would want a new version of postgres. -rocco > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Bruce Momjian > Sent: Wednesday, February 01, 2006 12:11 PM > To: Seneca Cunningham > Cc: Martijn van Oosterhout; pgsql-hackers@postgresql.org > Subject: Re: [HACKERS] Some platform-specific MemSet research > > > > My guess is that there is some really fast assembler for > memory copy on > AIX, and only libc memset() has it. If you want, we can make > MEMSET_LOOP_LIMIT in c.h a configure value, and allow template/aix to > set it to zero, causing memset() to be always used. > > Are you prepared to make this optimization decision for all AIX users > using gcc, or only for certain versions? > > -- > - > > Seneca Cunningham wrote: > > Martijn van Oosterhout wrote: > > > On Tue, Jan 24, 2006 at 05:24:28PM -0500, Seneca Cunningham wrote: > > > > > >>After reading the post on -patches proposing that MemSet > be changed to > > >>use long instead of int32 on the grounds that a pair of > x86-64 linux > > >>boxes took less time to execute the long code 64*10^6 > times[1], I took a > > >>look at how the testcode performed on AIX with gcc. > While the switch to > > >>long did result in a minor performance improvement, dropping the > > >>MemSetLoop in favour of the native memset resulted in the > tests taking > > >>~25% the time as the MemSetLoop-like int loop. The 32-bit > linux system I > > >>ran the expanded tests on showed that for the buffer size > range that > > >>postgres can use the looping MemSet instead of memset > (size <= 1024 > > >>bytes), MemSet generally had better performance. > > > > > > > > > Could you please check the asm output to see what's going > on. We've had > > > tests like these produce odd results in the past because > the compiler > > > optimised away stuff that didn't have any effect. Since > every memset > > > after the first is a no-op, you want to make sure it's > still actually > > > doing the work... > > > > Well, on both linux and AIX, all 30 of the 6400 iterations loops > > from the source exist (10 int, 10 long, 10 memset). According to my > > understanding of the assembler, memset itself is only > called for values > > >= 64 bytes on both platforms and the memset is called in > each iteration. > > > > The assembler for the 64 byte loops, with prepended line > number, first > > loop MemSetLoop int-variant, second loop memset, third loop > MemSetLoop > > long-variant: > > > > 64-bit AIX: > > > > 419 addi 3,1,112 > > 420 li 4,0 > > 421 bl .gettimeofday > > 422 nop > > 423 lis 10,0x3d0 > > 424 cmpld 6,26,16 > > 425 li 11,0 > > 426 ori 10,10,36864 > > 427 L..41: > > 428 bge 6,L..42 > > 429 mr 9,26 > > 430 li 0,0 > > 431 L..44: > > 432 stw 0,0(9) > > 433 addi 9,9,4 > > 434 cmpld 7,16,9 > > 435 bgt 7,L..44 > > 436 L..42: > > 437 addi 0,11,1 > > 438 extsw 11,0 > > 439 cmpw 7,11,10 > > 440 bne+ 7,L..41 > > 441 li 4,0 > > 442 mr 3,22 > > 443 lis 25,0x3d0 > > 444 li 28,0 > > 445 bl .gettimeofday > > 446 nop > > 447 li 4,64 > > 448 addi 5,1,112 > > 449 ld 3,LC..9(2) > > 450 mr 6,22 > > 451 ori 25,25,36864 > > 452 bl .print_time > > 453 addi 3,1,112 > > 454 li 4,0 > > 455 bl .gettimeofday > > 456 nop > > 457 L..46: > > 458 mr 3,26 > > 459 li 4,0 > > 460 li 5,64 > > 461 bl .memset > > 462 nop > > 463 addi 0,28,1 > > 464 extsw 28,0 > > 465 cmpw 7,28,25 > > 466 bne+ 7,L..46 > > 467 li 4,0 > > 468 mr 3,22 > > 469 bl .gettimeofday > > 470 nop > > 471 li 4,64 > > 472 addi 5,1,112 > > 473 ld 3,LC..11(2) > > 474 mr 6,22 > > 475 bl .print_time > > 476 addi 3,1,112 > > 477 li 4,0 > > 478 bl .gettimeofday > > 479 nop > > 480 lis 10,0x3d0 > > 481 cmpld 6,26,16 > > 482 li 11,0 > > 483 ori 10,10,36864 > > 484 L..48: > > 485 bge 6,L..49 > > 486 mr 9,26 > > 487 li 0,0 > > 488 L..51: > > 489 std 0,0(9) > > 490 addi 9,9,8 > > 491 cmpld 7,9,16 > > 492 blt 7,L..51 > > 493 L..49: > > 494 addi 0,11,1 > > 495 extsw 11,0 > > 496 cmpw 7,11,10 > > 497 bne+ 7,L..48 > > 498 li 4,0 > > 499 mr 3,2
Re: [HACKERS] [PORTS] Failed install - libgen.so doesn't exist
The reason to check versions is that AIX added support for standard dlopen at 4.3 and above, which means we don't need to use the port routines built around the older library any more. -rocco > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Martijn van Oosterhout > Sent: Tuesday, February 07, 2006 12:28 AM > To: Chris Browne > Cc: pgsql-hackers@postgresql.org > Subject: Re: [HACKERS] [PORTS] Failed install - libgen.so > doesn't exist > > > On Mon, Feb 06, 2006 at 04:45:11PM -0500, Chris Browne wrote: > > Further, it appears to be AIX pre-4.3 only, when using it > for dlopen() > > replacement... > > > > It would be an attractive idea to have configure detect not whether > > it's open, but rather whether it is needed, and leave it out for AIX > > 4.3 and "better"... > > That's kinda the point of these discussions, to answer the question: > what is in those libraries we need? Which symbol did we want? Rather > than trying to detect versions, is there some change in the library > (added or removed symbol) that we can base our decision on? > > Does that library (ld) actually provide dlopen() or something else? > > Thanks for the info. > -- > Martijn van Oosterhout > http://svana.org/kleptog/ > > Patent. n. Genius is 5% > inspiration and 95% perspiration. A patent is a > > tool for doing 5% of the work and then sitting around > waiting for someone > > else to do the other 95% so you can sue them. > ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[HACKERS] FW: PGBuildfarm member asp Branch HEAD Status changed from OK to Make failure
It looks like all buildfarm members are failing this morning... Here is an example. -rocco -Original Message- From: PG Build Farm [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 08, 2006 5:32 AM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: PGBuildfarm member asp Branch HEAD Status changed from OK to Make failure The PGBuildfarm member asp had the following event on branch HEAD: Status changed from OK to Make failure The snapshot timestamp for the build that triggered this notification is: 2006-02-08 10:23:00 The specs of this machine are: OS: AIX / 5.2 Arch: powerpc Comp: gcc / 3.3.2 For more information, see http://www.pgbuildfarm.org/cgi-bin/show_history.pl?nm=asp&br=HEAD ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] ANSI-strict pointer aliasing rules
> I suspect a patch to convert PostgreSQL to C++ wouldn't be > welcomed. Haha... > Checking my calendar, I think you are about 26 days too late to make that suggestion... -rocco ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] SO_SNDBUF size is small on win32?
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Martijn van Oosterhout > On Wed, Jun 28, 2006 at 12:23:13AM +0900, Yoshiyuki Asaba wrote: > > Hi, > > > > I see a performance issue on win32. This problem is causes by the > > following URL. > > > > http://support.microsoft.com/kb/823764/EN-US/ > > > > On win32, default SO_SNDBUF value is 8192 bytes. And > libpq's buffer is > > 8192 too. > > Ok, so there's a difficiency in Windows TCP code. Do you have any > benchmarks to show this actually makes a difference. According to the > URL you give, the problem occurs if the libpq buffer is *bigger* than > the socket buffer, which it isn't... > The article also says there is a problem if they are the same size. -rocco ---(end of broadcast)--- TIP 6: explain analyze is your friend
[HACKERS] AIX buildfarm failure
I am seeing buildfarm failures on AIX because stdio.h is being included before pg_config.h (which has the definition of _LARGE_FILES). The problem is stemming from math.h including stdlib.h, which (after several more inclusions) ends up including stdio.h. This is where the fgetpos64 different definitions is coming from. If I move down after "postgres.h" in nodeHash.c, the problem goes away. Do we want to consider putting math.h into the standard include set? Or is there a general rule that postgres.h needs to be the first include file (before system headers, etc)? Thanks, -rocco ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] AIX buildfarm failure
Now it dies on nodeSubplan.c... I am guessing there will be others as well. Perhaps a check to make sure postgres.h is first in the includes can be added to the include checking scripts you have been updating? Thanks, -rocco > -Original Message- > From: Bruce Momjian [mailto:[EMAIL PROTECTED] > Sent: Thursday, July 13, 2006 4:14 PM > To: Tom Lane > Cc: Rocco Altier; pgsql-hackers@postgresql.org > Subject: Re: [HACKERS] AIX buildfarm failure > > > > Fixed. > > -- > ----- > > Tom Lane wrote: > > "Rocco Altier" <[EMAIL PROTECTED]> writes: > > > If I move down after "postgres.h" in nodeHash.c, > the problem > > > goes away. > > > > Bruce, you broke it. Have you forgotten the fundamental > inclusion rule? > > postgres.h (or postgres_fe.h, or c.h) first, then system > headers, then > > our own other headers. > > > > regards, tom lane > > -- > Bruce Momjian [EMAIL PROTECTED] > EnterpriseDBhttp://www.enterprisedb.com > > + If your life is a hard drive, Christ can be your backup. + > ---(end of broadcast)--- TIP 6: explain analyze is your friend
