[HACKERS] Problem in buidind Postgres with mingw
Hello we've some trouble with buildinq postgreSQL (8.1.4.tar.gz) from code with Mingw on a windows xp home machine. We've installed mingw 5.0.3 and msys 1.0.10. From the msys console we've typed the following command: $ LDFLAGS=-lstdc++ configure --without-zlib and that's seems ok. then we do: $make the outcome is the following: Paolo [EMAIL PROTECTED] /d/msys/1.0/home/src/postgresql-8.1.4 $ make make -C doc all make[1]: Entering directory `/d/msys/1.0/home/src/postgresql-8.1.4/doc' gzip -d -c man.tar.gz | /bin/tar xf - for file in man1/*.1; do \ mv $file $file.bak \ sed -e 's/\\fR(l)/\\fR(7)/' $file.bak $file \ rm -f $file.bak || exit; \ done /bin/sh.exe ../config/mkinstalldirs man7 mkdir -p -- man7 for file in manl/*.l; do \ sed -e '/^\.TH/s/l/7/' \ -e 's/\\fR(l)/\\fR(7)/' \ $file man7/`basename $file | sed 's/.l$/.7/'` || exit; \ done make[1]: Leaving directory `/d/msys/1.0/home/src/postgresql-8.1.4/doc' make -C src all make[1]: Entering directory `/d/msys/1.0/home/src/postgresql-8.1.4/src' make -C port all make[2]: Entering directory `/d/msys/1.0/home/src/postgresql-8.1.4/src/port' gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Winline -Wdeclaration-after- statement -Wendif-labels -fno-strict-aliasing -I../../src/port -DFRONTEND -I../. ./src/include -I./src/include/port/win32 -DEXEC_BACKEND -I../../src/include/po rt/win32 -c -o crypt.o crypt.c gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Winline -Wdeclaration-after- statement -Wendif-labels -fno-strict-aliasing -I../../src/port -DFRONTEND -I../. ./src/include -I./src/include/port/win32 -DEXEC_BACKEND -I../../src/include/po rt/win32 -c -o fseeko.o fseeko.c gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Winline -Wdeclaration-after- statement -Wendif-labels -fno-strict-aliasing -I../../src/port -DFRONTEND -I../. ./src/include -I./src/include/port/win32 -DEXEC_BACKEND -I../../src/include/po rt/win32 -c -o getrusage.o getrusage.c In file included from ../../src/include/rusagestub.h:17, from getrusage.c:18: d:/MinGW/bin/../lib/gcc/mingw32/3.4.2/../../../../include/sys/time.h:27: error: redefinition of `struct timezone' d:/MinGW/bin/../lib/gcc/mingw32/3.4.2/../../../../include/sys/time.h:40: error: conflicting types for 'gettimeofday' ../../src/include/port.h:266: error: previous declaration of 'gettimeofday' was here d:/MinGW/bin/../lib/gcc/mingw32/3.4.2/../../../../include/sys/time.h:40: error: conflicting types for 'gettimeofday' ../../src/include/port.h:266: error: previous declaration of 'gettimeofday' was here make[2]: *** [getrusage.o] Error 1 make[2]: Leaving directory `/d/msys/1.0/home/src/postgresql-8.1.4/src/port' make[1]: *** [all] Error 2 make[1]: Leaving directory `/d/msys/1.0/home/src/postgresql-8.1.4/src' make: *** [all] Error 2 Please can somebody help us? Claudio. Maurizio. Paolo. -- Chi punta sullÂ’inglese naturale Wall Street Institute, vince un English Box! Scopri come ritirare i tuoi premi, clicca qui! http://click.libero.it/wallstreet14nov ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
[HACKERS] Segmentation fault with HEAD.
Hi. I just compiled the version in HEAD with no problems. I connected with template1, made some tests and quited. I got the following error: template1=# \q psql(15213) malloc: *** error for object 0x1804e00: incorrect checksum for freed object - object was probably modified after being freed, break at szone_error to debug psql(15213) malloc: *** set a breakpoint in szone_error to debug Segmentation fault Now. I can't find a list of knows bug to compare agains, so sorry if this is a know bug. If you need more information, please let me know how to record these, and I will post them as soon as possible. Rune ---(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] Remove contrib version of rtree_gist --- now in core system ?
Hello everybody!Remove contrib version of rtree_gist --- now in core system ?I have read that since version 8.1 the contrib version of rtree_gist is not in /contrib anymore, now is in core system, but where can I find it? regards Jorge
Re: [HACKERS] Problem in buidind Postgres with mingw
[EMAIL PROTECTED] wrote: Hello we've some trouble with buildinq postgreSQL (8.1.4.tar.gz) from code with Mingw on a windows xp home machine. My experience is that XP-Pro is a better platform for building postgres than XP-HE. We've installed mingw 5.0.3 and msys 1.0.10. From the msys console we've typed the following command: $ LDFLAGS=-lstdc++ configure --without-zlib Why are you trying to link in this library? That seems dangerous, to say the least. and that's seems ok. then we do: $make the outcome is the following: Paolo [EMAIL PROTECTED] /d/msys/1.0/home/src/postgresql-8.1.4 Why did you not install msys and mingw in the standard locations and then just use the standard paths (/usr, /home etc). cheers andrew ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Remove contrib version of rtree_gist --- now in core system ?
jorge alberto [EMAIL PROTECTED] writes: I have read that since version 8.1 the contrib version of rtree_gist is not in /contrib anymore, now is in core system, but where can I find it? You don't need to find it, it's built in. Just create an index. regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
[HACKERS] Help me pack up postgresDB with my windows application.
Dear hackers,I'm working ona windows application with C# language and use npgsql to connectpostgres DB. I'm eager to learn how to make a solo setup file which included windows application and postgres DB. My develop environment is Visual Studio 2003 and Framework 1.1I don't know if there are a convenient way to pack upa postgres DB, and I'm not sure which files and register key I need to pack, as well as how to turn up apostgres service after installation.I knowmany peoplelike you have done wonderful job on postgres and it is unsuspectingly. Ijust want toreduce steps, config-operation and keep database passwordwhen our userinstall applications. Very appreciate your help. James Duan Everyone is raving about the all-new Yahoo! Mail beta.
Re: [HACKERS] Help me pack up postgresDB with my windows application.
du li wrote: Dear hackers, I'm working on a windows application with C# language and use npgsql to connect postgres DB. I'm eager to learn how to make a solo setup file which included windows application and postgres DB. My develop environment is Visual Studio 2003 and Framework 1.1 I don't know if there are a convenient way to pack up a postgres DB, and I'm not sure which files and register key I need to pack, as well as how to turn up a postgres service after installation. I know many people like you have done wonderful job on postgres and it is unsuspectingly. I just want to reduce steps, config-operation and keep database password when our user install applications. http://pgfoundry.org/projects/pginstaller/ contains a link to the source used to build the windows binary installer - what you want will be in there. -- Shane Ambler [EMAIL PROTECTED] Get Sheeky @ http://Sheeky.Biz ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] [SQL] Case Preservation disregarding case sensitivity?
beau hargis wrote: Having installed DB2 Enterprise today and taking it for a spin, it does indeed behave in a similar manner. However, after reading through both specifications, it seems that DB2 follows more of the spec than PostgreSQL. The specifications state that for purpose of comparing identifiers, both shall be converted to upper-case. DB2 displays all identifiers in upper-case whereas PostgreSQL displays all identifiers in lower-case. This alone would be a deviation from the specification. True. We lowercase because historically we have, and because all-upper-case is hard to read. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Segmentation fault with HEAD.
Rune, This is a readline issue of some sort. Basically this seg fault happens when you quit and the .psql_history file changes. I don't really know why it happens and what the right solution is but if you empty the contents of this file (or maybe delete it) then your seg fault will go away (until it will show up again in few months or so :-) ). This is not THE proper solution probably but it does the job. Alon. On 11/14/06 4:49 AM, Rune Bromer [EMAIL PROTECTED] wrote: Hi. I just compiled the version in HEAD with no problems. I connected with template1, made some tests and quited. I got the following error: template1=# \q psql(15213) malloc: *** error for object 0x1804e00: incorrect checksum for freed object - object was probably modified after being freed, break at szone_error to debug psql(15213) malloc: *** set a breakpoint in szone_error to debug Segmentation fault Now. I can't find a list of knows bug to compare agains, so sorry if this is a know bug. If you need more information, please let me know how to record these, and I will post them as soon as possible. Rune ---(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 6: explain analyze is your friend
Re: [HACKERS] TODO Item: IN(long list ...)
Alvaro Herrera wrote: Josh Berkus wrote: Bruce, all: This is a longstanding performance issue which just came up again on IRC, and I can't find a TODO item for it. So I'd like it added to TODO. Suggested phrasing: -- Improve performance of queries with IN() clauses containing hundreds or more literal values, possibly by re-writing it as a join to a virtual table. Hmm, wasn't there some work on this regard in 8.2? Yes. It was fixed by Joe Conway when it was discovered, so never made it on the TODO list. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(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] Segmentation fault with HEAD.
Alon Goldshuv wrote: Rune, This is a readline issue of some sort. Basically this seg fault happens when you quit and the .psql_history file changes. I don't really know why it happens and what the right solution is but if you empty the contents of this file (or maybe delete it) then your seg fault will go away (until it will show up again in few months or so :-) ). This is not THE proper solution probably but it does the job. Thank you very much, I'll verify this tomorrow and return if the error persists. What led you to the conclusion that it was a readline error? I looked into it for a couple of hours, but as I'm new to the postgres source code I cound't find the error :) Rune ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Segmentation fault with HEAD.
Thank you very much, I'll verify this tomorrow and return if the error persists. What led you to the conclusion that it was a readline error? I looked into it for a couple of hours, but as I'm new to the postgres source code I cound't find the error :) For the life of me I can't remember! That was some time ago. It sure wasn't obvious to me - took some time. I think few of my colleagues were having some issues with Apple's default readline and they had to install a 3rd party readline. I didn't get around to doing that yet. Is your error on a mac os? ---(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] [SQL] Case Preservation disregarding case
On Thu, 2006-11-02 at 10:51 -0500, Tom Lane wrote: Simon Riggs [EMAIL PROTECTED] writes: We have namespaces to differentiate between two sources of object names, so anybody who creates a schema where MyColumn is not the same thing as myColumn is not following sensible rules for conceptual distance. I'd agree that that is not a good design practice, but the fact remains that they *are* different per spec. Would be better to make this behaviour a userset switchable between the exactly compliant and the more intuitive. That's certainly not happening --- if you make any changes in the semantics of equality of type name, it would have to be frozen no later than initdb time, for exactly the same reasons we freeze locale then (hint: index ordering). [Re-read all of this after Bruce's post got me thinking.] My summary of the thread, with TODO items noted: 1. PostgreSQL doesn't follow the spec, but almost does, with regard to comparison of unquoted and quoted identifiers. DB2 does this per spec. 2. TODO: We could follow the spec, but it would need an initdb option; some non-SQL:2003 standard PostgreSQL programs would not work as they do now. This is considered a minor, low priority item, though. 3. TODO: We could set column headers better if we wanted to (rather than ?column? we could use e.g. Sum_ColumnName etc) -- Simon Riggs EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
