Re: [PATCHES] [HACKERS] [COMMITTERS] pgsql: /contrib/cube improvements:
There is also an issue with PPC processors with +/-0 in the cube test: *** ./expected/cube.out Thu Jul 27 05:23:14 2006 --- ./results/cube.out Thu Jul 27 05:43:21 2006 *** *** 144,150 SELECT '-1e-700'::cube AS cube; cube -- ! (0) (1 row) SELECT '1234567890123456'::cube AS cube; --- 144,150 SELECT '-1e-700'::cube AS cube; cube -- ! (-0) (1 row) SELECT '1234567890123456'::cube AS cube; I am seeing a reodering of results issue on my AIX box, for both gcc and native CC. Check the buildfarm members asp and kookaburra. It looks like the alternate expected files need to be updated as well. -rocco -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Joshua Reich Sent: Thursday, July 27, 2006 11:04 AM To: Andrew Dunstan Cc: Tom Lane; pgsql-patches@postgresql.org Subject: Re: [PATCHES] [HACKERS] [COMMITTERS] pgsql: /contrib/cube improvements: You are correct. Patch against the latest HEAD attached. Josh Andrew Dunstan wrote: Joshua Reich wrote: Ok. Here is a diff taken from the top of the contrib tree. I have suppressed the notices in both the cube and earthdistance packages. All tests pass. Doesn't this contain parts that have been already applied? It looks to me like you need to do a cvs update (and then a subsequent clean and test) before generating the diff. cheers andrew ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] [PATCH] Improve EXPLAIN ANALYZE overhead by sampling
- To get this close it needs to get an estimate of the sampling overhead. It does this by a little calibration loop that is run once per backend. If you don't do this, you end up assuming all tuples take the same time as tuples with the overhead, resulting in nodes apparently taking longer than their parent nodes. Incidently, I measured the overhead to be about 3.6us per tuple per node on my (admittedly slightly old) machine. Could this be deferred until the first explain analyze? So that we aren't paying the overhead of the calibration in all backends, even the ones that won't be explaining? -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: [PATCHES] [HACKERS] pgxs/windows
If I understand correctly, atleast for the AIX case, the reason that Makefile.aix is referencing DESTDIR is for the PGXS case. I thought that PGXS was supposed to be able to be run after things were installed, and you might not have the compile tree anymore. Basically, if you wanted to build some extensions on top of a precompiled set of binaries. If we take the DESTDIR out of here, where should we get the POSTGRES_IMP file from? -rocco -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tom Lane Sent: Thursday, January 19, 2006 3:54 PM To: Bruce Momjian Cc: Andrew Dunstan; Magnus Hagander; PostgreSQL-patches Subject: Re: [PATCHES] [HACKERS] pgxs/windows Bruce Momjian pgman@candle.pha.pa.us writes: Tom Lane wrote: What about the question of whether $(DESTDIR) belongs there or not? I think we had concluded that PGXS shouldn't ever use $(DESTDIR), because that's only for install-time stuff. I considered that a separate issue and didn't explore it, but I think you are right that $(DESTDIR) makes no sense so I will remove it. Patch attached. If these are bogus then so are the uses in Makefile.aix and Makefile.darwin. I'm a bit bothered by the ones in pgxs.mk, too, although I suspect we have to leave those there for the benefit of contrib? regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] AIX - pgport/contrib resolution
Here is a backport of patches to get AIX to work on 8.0. Basically, it's the changes to : backend/Makefile - redo the linking of the SUBSYS objects contrib/cube - pick up -lm port/getopt_long.c - fix include files (might want to think about other files changed here too?) contrib/tsearch2 - similar include file fixes The tsearch2 part is the most invasive part of the patch, but I only brought over the parts that were stopping the compile directly, so it might not be the whole thing, since I was trying to minimize the impact on the code base. It might be possible to trim the tsearch down further to only the needed files, but I just brought over the include file fixes from HEAD directly - so that the branches would be more directly comparable to each other. Thanks, -rocco -Original Message- From: Andrew Dunstan [mailto:[EMAIL PROTECTED] Sent: Thursday, July 28, 2005 9:53 AM To: Tom Lane Cc: Rocco Altier; pgsql-patches@postgresql.org Subject: Re: [PATCHES] AIX - pgport/contrib resolution Tom Lane wrote: Pushed these in too ... hope to see a green board on the AIX buildfarm machines soon. That's what we have. Good work. Are these changes too intrusive to backpatch to 8.0? cheers andrew aix-backport-80 Description: aix-backport-80 ---(end of broadcast)--- TIP 6: explain analyze is your friend
[PATCHES] AIX - pgport/contrib resolution
The comment in regress/GNUmakefile about the pgport symbols not being found got me thinking about why that might be the case. I finally noticed that when we are building the postgres.imp file, we are not pulling in the pgport symbols, since they are not being linked into the local SUBSYS.o before running mkldexport.sh. I noticed that windows has a similar dilemma when creating the .def file. The solution was to suck in libpgport.a before we extract all the symbols out. A patch to that affect is attached. backend/Makefile - fix rule for AIX regarding pgport files port/getopt_long - needed to have optreset wrapped in HAVE_INT_OPTRESET regress/GNUmakefile - hopefully I backed out the change to bring in pgsleep well enough With these changes in place, I was able to complete a full build and test suite (including contrib). Thanks, -rocco aix-pgport-contrib.patch Description: aix-pgport-contrib.patch ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] Proposed patch to remove .so pattern rules from platform Makefiles
Please disregard this patch. I have a ton of lib%.exp and similar files created currently. I am working on a new patch to deal with the MODULES expansion correctly. Thanks, -rocco -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rocco Altier Sent: Monday, July 25, 2005 1:17 PM To: Tom Lane; pgsql-patches@postgresql.org Subject: Re: [PATCHES] Proposed patch to remove .so pattern rules from platform Makefiles The patch works on AIX with one small tweak to Makefile.shlib (attached). This is needed because of the clever trick with using % as name, and when its evaulated for the mkldexport. Also, it appears that the changes for regress/GNUmakefile are already applied. I am able to build everything and pass the regression tests. This just leaves the contrib/pgport issue from letting AIX go green on the buildfarm. Thanks for getting this simplification done! -rocco -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tom Lane Sent: Sunday, July 24, 2005 6:00 PM To: pgsql-patches@postgresql.org Subject: [PATCHES] Proposed patch to remove .so pattern rules from platform Makefiles I've wanted for a long time to get rid of the pattern rules in the port-specific Makefiles that generate shared libraries from single object files. These patterns duplicate (or, more often, fail to completely duplicate) the knowledge in Makefile.shlib. So from a maintenance point of view centralizing that knowledge is a good thing. The stumbling block has been partly that the regression-test makefile depended on the pattern rules (easily fixed by using Makefile.shlib) and partly that pgxs.mk (and its predecessor contrib-global.mk) depended on the pattern rules to handle Makefiles that wanted to build multiple .so files. Since Makefile.shlib is designed to handle only one shlib per build, there wasn't any obvious way to fix that. The attached proposed patch gets around this by invoking Makefile.shlib in a way that produces a pattern rule lib%.so : %.o. This is moderately ugly but it gets the job done without changing Makefile.shlib itself. Possibly it could be done more cleanly if we were willing to introduce pattern rules inside Makefile.shlib. I am not sure if the patch works on non-Unix platforms --- could someone test on Win32 and Cygwin, in particular? AIX is weird enough to need testing too. Any other comments? regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [PATCHES] Proposed patch to remove .so pattern rules from platform Makefiles
-Original Message- From: Tom Lane [mailto:[EMAIL PROTECTED] Rocco Altier [EMAIL PROTECTED] writes: Please disregard this patch. I have a ton of lib%.exp and similar files created currently. Yeah, that was one of the reasons I called it ugly :-(. I had put in an rm step to get rid of lib%.so, you could probably fix the extraneous .exp files similarly. If they are part of the rule, they get expanded, but if its part of the commands to run, they don't, which is where I was getting the lib%.exp from. I have gotten them to where they will be expanded for the .exp, so that there are the multiple files correctly, instead of just the one lib%.exp. I will look at doing the same for lib%.so, etc. Alternatively we could look at expanding Makefile.shlib to provide %.so pattern rules directly. If I am reading the affect on the makefiles correctly, that is basically what is happening. We get a bunch of pattern rules... From gmake -p (in contrib/spi - a multiple MODULES rule): lib%.a: %.o # commands to execute (from `../../src/Makefile.shlib', line 281): $(LINK.static) $@ $^ $(RANLIB) $@ lib%.so: lib%.a # commands to execute (from `../../src/Makefile.shlib', line 313): $(MKLDEXPORT) $ $(subst .a,$(EXPSUFF),$) $(COMPILER) $(LDFLAGS_SL) -o $@ $ $(LDFLAGS) $(SHLIB_LINK) -Wl,-bI:$(top_builddir)/src/backend/$(POSTGRES_IMP) -Wl,-bE:$(subst .a,$(EXPSUFF),$) %.so: lib%.so # commands to execute (from `../../src/makefiles/pgxs.mk', line 85): rm -f $@ ln $ $@ rm -f $(shlib_major) ... (Substituted rules with autoinc later..) My patch was more intended as proof of concept than anything we necessarily wanted to apply as-is. I have been trying to iron out some of the wrinkles, but over all its definitely a good place to start. Thanks, -rocco ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [PATCHES] Proposed patch to remove .so pattern rules from platform Makefiles
The patch works on AIX with one small tweak to Makefile.shlib (attached). This is needed because of the clever trick with using % as name, and when its evaulated for the mkldexport. Also, it appears that the changes for regress/GNUmakefile are already applied. I am able to build everything and pass the regression tests. This just leaves the contrib/pgport issue from letting AIX go green on the buildfarm. Thanks for getting this simplification done! -rocco -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tom Lane Sent: Sunday, July 24, 2005 6:00 PM To: pgsql-patches@postgresql.org Subject: [PATCHES] Proposed patch to remove .so pattern rules from platform Makefiles I've wanted for a long time to get rid of the pattern rules in the port-specific Makefiles that generate shared libraries from single object files. These patterns duplicate (or, more often, fail to completely duplicate) the knowledge in Makefile.shlib. So from a maintenance point of view centralizing that knowledge is a good thing. The stumbling block has been partly that the regression-test makefile depended on the pattern rules (easily fixed by using Makefile.shlib) and partly that pgxs.mk (and its predecessor contrib-global.mk) depended on the pattern rules to handle Makefiles that wanted to build multiple .so files. Since Makefile.shlib is designed to handle only one shlib per build, there wasn't any obvious way to fix that. The attached proposed patch gets around this by invoking Makefile.shlib in a way that produces a pattern rule lib%.so : %.o. This is moderately ugly but it gets the job done without changing Makefile.shlib itself. Possibly it could be done more cleanly if we were willing to introduce pattern rules inside Makefile.shlib. I am not sure if the patch works on non-Unix platforms --- could someone test on Win32 and Cygwin, in particular? AIX is weird enough to need testing too. Any other comments? regards, tom lane makefile.shlib Description: makefile.shlib ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] Regression - GNUmakefile - pg_usleep
I see what you are saying now. libpgport is not a shared library - because of AIX's funny linking, I had not noticed that before. You propose making it similar to libpq. By that do you mean breaking it into 2 separate diretories - backend/libpq interfaces/libpq - so that we create the libraries pgport and pgport_srv from different directories - possibly using the existing backend/port and port? If you mean something else, let me know so that I might persue that path. In the mean time, an AIX specific patch(hack) would be to shove -lpgport into BE_DLLLIB in Makefile.aix - patch attached. Thanks -rocco (desperate to get AIX green on buildfarm) -Original Message- From: Tom Lane [mailto:[EMAIL PROTECTED] Sent: Sunday, July 24, 2005 7:34 PM To: Rocco Altier Cc: Patches (PostgreSQL) Subject: Re: [PATCHES] Regression - GNUmakefile - pg_usleep Rocco Altier [EMAIL PROTECTED] writes: This time I actually have the patches :-) I've applied the parts of this that add -lm to contrib modules, but not the parts that add -lpgport. That's because libpgport is not built to be relocatable, and so including it fails hard on platforms that care: /usr/ccs/bin/ld +h libtsearch2.sl.0 -b +b /home/postgres/testversion/lib dict_ex.o dict.o snmap.o stopword.o common.o prs_dcfg.o dict_snowball.o dict_ispell.o dict_syn.o wparser.o wparser_def.o ts_cfg.o tsvector.o rewrite.o crc32.o query.o gistidx.o tsvector_op.o rank.o ts_stat.o snowball/SUBSYS.o ispell/SUBSYS.o wordparser/SUBSYS.o -L../../src/port -L/usr/local/lib -lpgport -lm `gcc -L../../src/port -Wl,-z -Wl,+b -Wl,/home/postgres/testversion/lib -print-libgcc-file-name` -o libtsearch2.sl.0 /usr/ccs/bin/ld: DP relative code in file ../../src/port/libpgport.a(exec.o) - shared library must be position independent. Use +z or +Z to recompile. make: *** [libtsearch2.sl.0] Error 1 We will need to either eliminate the dependencies on libpgport, or use the extra-compilation technique used in, eg, libpq. regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] fix integer datetime division rounding error
This fixes the problem for me. Thanks, -rocco -Original Message- From: Bruce Momjian [mailto:[EMAIL PROTECTED] Sent: Sunday, July 24, 2005 12:37 AM To: Andrew Dunstan Cc: Patches (PostgreSQL); Rocco Altier Subject: Re: [PATCHES] fix integer datetime division rounding error Andrew Dunstan wrote: The attached patch seems to fix the rounding error that is causing regression failures on machines with integer datetimes. (Source of error discovered by [EMAIL PROTECTED]).ISTM this code needs to be given some careful analysis - I know it makes my head spin reading it. Ah, brilliant! I knew I was missing something fundamental, and the use of rint() was it. Strangely enough, the 8.0 code uses rint() in that function, but for floating point intervals, and the code was buggy, generating negative time values for division. Patch attached and applied. I also improved the interval multiplication code. -- 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 2: Don't 'kill -9' the postmaster
Re: [PATCHES] Regression - GNUmakefile - pg_usleep
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tom Lane Sent: Sunday, July 24, 2005 10:47 AM To: Rocco Altier Cc: Patches (PostgreSQL) Subject: Re: [PATCHES] Regression - GNUmakefile - pg_usleep Rocco Altier [EMAIL PROTECTED] writes: Attached patch fixes the SHLIB_LINK to add pgport now that pg_usleep is added. It seems highly unlikely that this will accomplish anything, given that SHLIB_LINK is not used to construct regress.so. I have another patch in queue for this. This is needed for AIX to resolve symbols at compile time. I'm still wondering why that platform has such a hard time finding symbols that are in the backend. Right now there are 2 different sets of linker rules. One for a single file - .so (from Makefile.aix), and another for multiple files - libfiles.so (from Makefile.shlib). The patch I proposed to Makefile.shlib to pull all $LIBS in was rejected since this would cause libpq to link against backend libraries, etc. The suggested solution was to only pull in libraries as needed (which is what is happening here, since pgport would be required). I think the 2 sets of link rules should be more similar, since the contrib moudules should get the same link option, instead of based on how many files need to be linked together, thus Makefile.aix should be changed to use SHLIB_LINK. I am attaching all the patches for so for AIX to let it get past Contrib on the buildfarm. Makefile.aix.patch - will bring Makefile.aix in line with Makefile.shlib by using SHLIB_LINK contrib.libs.patch - will pull in the needed libraries for contrib modules regress.pgport.patch - same idea as contrib patch, pull in the needed library I hope this makes it a bit clearer what I am trying to achieve by having all the pieces together in one place. Thanks, -rocco PS. I am starting to look at using the facilities in AIX to support run time linked libraries instead of at compile time. This does require AIX 4.2+, so I will try to leave the 4.1 code in place. ---(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] Regression - GNUmakefile - pg_usleep
This time I actually have the patches :-) -rocco -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rocco Altier Sent: Sunday, July 24, 2005 1:15 PM To: Tom Lane Cc: Patches (PostgreSQL) Subject: Re: [PATCHES] Regression - GNUmakefile - pg_usleep -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tom Lane Sent: Sunday, July 24, 2005 10:47 AM To: Rocco Altier Cc: Patches (PostgreSQL) Subject: Re: [PATCHES] Regression - GNUmakefile - pg_usleep Rocco Altier [EMAIL PROTECTED] writes: Attached patch fixes the SHLIB_LINK to add pgport now that pg_usleep is added. It seems highly unlikely that this will accomplish anything, given that SHLIB_LINK is not used to construct regress.so. I have another patch in queue for this. This is needed for AIX to resolve symbols at compile time. I'm still wondering why that platform has such a hard time finding symbols that are in the backend. Right now there are 2 different sets of linker rules. One for a single file - .so (from Makefile.aix), and another for multiple files - libfiles.so (from Makefile.shlib). The patch I proposed to Makefile.shlib to pull all $LIBS in was rejected since this would cause libpq to link against backend libraries, etc. The suggested solution was to only pull in libraries as needed (which is what is happening here, since pgport would be required). I think the 2 sets of link rules should be more similar, since the contrib moudules should get the same link option, instead of based on how many files need to be linked together, thus Makefile.aix should be changed to use SHLIB_LINK. I am attaching all the patches for so for AIX to let it get past Contrib on the buildfarm. Makefile.aix.patch - will bring Makefile.aix in line with Makefile.shlib by using SHLIB_LINK contrib.libs.patch - will pull in the needed libraries for contrib modules regress.pgport.patch - same idea as contrib patch, pull in the needed library I hope this makes it a bit clearer what I am trying to achieve by having all the pieces together in one place. Thanks, -rocco PS. I am starting to look at using the facilities in AIX to support run time linked libraries instead of at compile time. This does require AIX 4.2+, so I will try to leave the 4.1 code in place. ---(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 Makefile.aix.patch Description: Makefile.aix.patch contrib.libs.patch Description: contrib.libs.patch regress.pgport.patch Description: regress.pgport.patch ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] [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 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
Re: [PATCHES] [HACKERS] regressin failure on latest CVS
That still does not fix it for me. This patch is still using a computed float value (month_remainder and day_remainder), which is cauing the rounding errors. There are now 6 machines on the build farm that are failing from the rounding: Wallaroo (OSX/G4), asp(AIX/powerpc), viper(FC3/x86_64), platypus(FBSD/amd64), kookaburra(AIX/powerpc), oriole(FC4/x86). All of these are using enable-integer-datetimes. What was wrong with the patch I sent? I am doing as much as I can with integer math. -rocco -Original Message- From: Bruce Momjian [mailto:[EMAIL PROTECTED] Sent: Saturday, July 23, 2005 2:51 PM To: Rocco Altier Cc: Michael Glaesemann; pgsql-patches@postgresql.org; ohp@pyrenet.fr Subject: Re: [HACKERS] regressin failure on latest CVS Would you please try the attached patch and let me know if it fixes the problem? I avoided accumulating into a float8. -- - Rocco Altier wrote: 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 -- 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 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
[PATCHES] Regression - GNUmakefile - pg_usleep
Attached patch fixes the SHLIB_LINK to add pgport now that pg_usleep is added. This is needed for AIX to resolve symbols at compile time. This is also to be used in conjuction with the other patch I have pending for Makefile.aix to SHLIB_LINK instead of LIBS to compile shared objects. Thanks, -rocco regress_makefile.patch Description: regress_makefile.patch ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] Changes for AIX buildfarm
Attached is a patch for HEAD to implement Peter's suggestion to set the SHLIB_LINK in the contrib modules that need it. Also, this changes Makefile.aix to use SHLIB_LINK instead of LIBS so that the changes to the contrib Makefiles are picked up correctly. Further this makes it match more closely the link rules from Makefile.shlib. -rocco -Original Message- From: Peter Eisentraut [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 20, 2005 2:12 PM To: Rocco Altier Cc: pgsql-patches@postgresql.org; Tom Lane; Andrew Dunstan; Zeugswetter Andreas DAZ SD Subject: Re: [PATCHES] Changes for AIX buildfarm Tom Lane wrote: Fair enough. But I'm concerned about the proposed patch because it seems to revert a deliberate change made some time ago: http://developer.postgresql.org/cvsweb.cgi/pgs ql/src/Makefile.shlib#r ev1.65 http://archives.postgresql.org/pgsql-committers/2002-10/msg00054.php so I think we need more eyeballs on the problem before deciding this is a good fix. A potentially more correct solution would be to set SHLIB_LINK in the makefiles of the affected modules only. Certainly we don't want to link with all libraries all the time. -- Peter Eisentraut http://developer.postgresql.org/~petere/ aix.contrib.patch Description: aix.contrib.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: [PATCHES] [COMMITTERS] pgsql: Add 'day' field to INTERVAL so 1 day interval
This is also broken for make check with --enable-integer-datetimes on kookaburra (AIX). It looks like the other members of buildfarm that fail on contrib aren't using integer datetimes. -rocco -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bruce Momjian Sent: Wednesday, July 20, 2005 2:21 PM To: Kris Jurka Cc: PostgreSQL-patches Subject: Re: [PATCHES] [COMMITTERS] pgsql: Add 'day' field to INTERVAL so 1 day interval Kris Jurka wrote: Bruce Momjian wrote: Log Message: --- Add 'day' field to INTERVAL so 1 day interval can be distinguished from 24 hours. This is very helpful for daylight savings time: Seems to have broken the contrib/btree_gist interval regression tests http://pgbuildfarm.org/cgi-bin/show_log.pl?nm=dragonflydt=200 5-07-20%2017:30:00 I have applied a patch which adds the 'date' value for interval to the code. However, the regression still does not pass. Here is a query: SELECT count(*) FROM intervaltmp WHERE a = '199 days 21:21:23'::interval; count --- 1 (1 row) that should return 1, but returns 0 in the current code. Does anyone have any ideas on a fix? -- 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 ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
[PATCHES] Changes for AIX buildfarm
Need to have these patches applied to get AIX 5.2 to build as a member of the buildfarm. The Makefile.shlib patch allows all the contrib modules to build (this seems to be the same problem that cygwin is facing). AIX needs -lm (to pick up math routines for atleast cube module). I am not sure why the other platforms build without this. There are C++ style comments in contrib/pgcrypto which is giving cc problems. Thanks, -rocco Makefile.shlib.patch Description: Makefile.shlib.patch pg_crypto.patch Description: pg_crypto.patch ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] Changes for AIX buildfarm
It looks like I jumped the gun a bit on sending out the patches, since I was intending to have the failed build report show up in the buildfarm at the same time. I am running another build with send so that the error will show on the build farm. The animal name is appropiately: kookaburra -rocco -Original Message- From: Andrew Dunstan [mailto:[EMAIL PROTECTED] Sent: Monday, July 18, 2005 12:42 PM To: Tom Lane Cc: Rocco Altier; pgsql-patches@postgresql.org Subject: Re: [PATCHES] Changes for AIX buildfarm Tom Lane wrote: Rocco Altier [EMAIL PROTECTED] writes: Need to have these patches applied to get AIX 5.2 to build as a member of the buildfarm. Er, which buildfarm report is prompting this? Rocco is probably doing what I normally ask, which is to get builds working before starting to upload results to the buildfarm server (a request which is more honored in the breach than the observance). cheers andrew ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] Changes for AIX buildfarm
The problem trying to be fixed there seems to be related to libraries being linked into the backend vs. frontend. Since the contrib shared library modules are linked in a similar environment backend code I decided to use BE_DLLLIBS. Here is the new patch (which doesn't affect libpq). -rocco Index: src/makefiles/Makefile.aix === RCS file: /projects/cvsroot/pgsql/src/makefiles/Makefile.aix,v retrieving revision 1.21 diff -c -r1.21 Makefile.aix *** src/makefiles/Makefile.aix 9 Oct 2002 16:21:54 - 1.21 --- src/makefiles/Makefile.aix 18 Jul 2005 19:59:59 - *** *** 15,20 --- 15,21 LDFLAGS_SL = -Wl,-bnoentry -Wl,-H512 -Wl,-bM:SRE endif + BE_DLLLIBS= $(LIBS) EXPSUFF= .exp IMPSUFF= .imp -Original Message- From: Tom Lane [mailto:[EMAIL PROTECTED] Sent: Monday, July 18, 2005 12:47 PM To: Andrew Dunstan Cc: Rocco Altier; Zeugswetter Andreas DAZ SD; pgsql-patches@postgresql.org Subject: Re: [PATCHES] Changes for AIX buildfarm Andrew Dunstan [EMAIL PROTECTED] writes: Tom Lane wrote: Er, which buildfarm report is prompting this? Rocco is probably doing what I normally ask, which is to get builds working before starting to upload results to the buildfarm server (a request which is more honored in the breach than the observance). Fair enough. But I'm concerned about the proposed patch because it seems to revert a deliberate change made some time ago: http://developer.postgresql.org/cvsweb.cgi/pgsql/src/Makefile.shlib#rev1 .65 http://archives.postgresql.org/pgsql-committers/2002-10/msg00054.php so I think we need more eyeballs on the problem before deciding this is a good fix. regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] Changes for AIX buildfarm
I have looked more closely at what is happening during the link of the contrib modules, and I agree that my original patch is too broad. I am seeing that cube fails, but userlocks works. I have noticed that cube is using a MODULE_big directive (which is failing to pick up all libraries), but that userlocks is using MODULES which is working correctly. I will dig further and come up with another patch. -rocco -Original Message- From: Tom Lane [mailto:[EMAIL PROTECTED] Sent: Monday, July 18, 2005 12:47 PM To: Andrew Dunstan Cc: Rocco Altier; Zeugswetter Andreas DAZ SD; pgsql-patches@postgresql.org Subject: Re: [PATCHES] Changes for AIX buildfarm Andrew Dunstan [EMAIL PROTECTED] writes: Tom Lane wrote: Er, which buildfarm report is prompting this? Rocco is probably doing what I normally ask, which is to get builds working before starting to upload results to the buildfarm server (a request which is more honored in the breach than the observance). Fair enough. But I'm concerned about the proposed patch because it seems to revert a deliberate change made some time ago: http://developer.postgresql.org/cvsweb.cgi/pgsql/src/Makefile.shlib#rev1 .65 http://archives.postgresql.org/pgsql-committers/2002-10/msg00054.php so I think we need more eyeballs on the problem before deciding this is a good fix. regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
