[BUGS] BUG #3513: buggy install + no manual support (add)
The following bug has been logged online: Bug reference: 3513 Logged by: Lamia Jackson Email address: [EMAIL PROTECTED] PostgreSQL version: 8.2.4.1 Operating system: win32 Description:buggy install + no manual support (add) Details: These parts of installation didn't install properly: procedural langs, contrib files, PostGIS In fact it doesn't have anything with port cause after reinstalling, i couldn't do that just with modifing installation (just i cant change def language and codepage), it stay the same ... installed but not activated whatever it means. What's even worse it seems that evenm i unistalled old postgres and newlly install it i still have language i don't wan't (even if i choose different during the installation it stays the same i choose during THE FIRST) and English_US is in the registry (found thru log) but not in console when exceptions are thrown. And when i try to createdb sagfargu i get these message in some other lang these are reconstructed from log "server closed the connection unexpectedly. This probably means the server terminated abnormally before or while processing the request." cause in the same way these unproperly installed parts terminated and write that to the log. ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [BUGS] BUG #3512: buggy install + no manual support
Lamia Jackson wrote: > The following bug has been logged online: > > Bug reference: 3512 > Logged by: Lamia Jackson > Email address: [EMAIL PROTECTED] > PostgreSQL version: 8.2.4.1 > Operating system: win32 > Description:buggy install + no manual support > Details: > > before completing installation i recieve an installer exception that > packages (PostGIS, PL/Java, Slony-I) couldn't be activated. how could i > activate them manually and test that i'm sure that i done that. Probable for > all reason might be changing pgsql port from 5432 What error message did you get exactly? > and very important for me. i'dont see an chapter in a manual that tell's me > how could i execute manually an SQL script for additional templates that > could be called per base needs. I left only Adminpack (preselected one) in > hope that the rest of them could easily be scripted if i need them in > creating a new database. You do that using psql - see http://www.postgresql.org/docs/8.2/static/app-psql.html. But yeah, that's far from obvious if you don't know where to look. //Magnus ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
[BUGS] BUG #3516: Incomplete #ifdef statement in s_lock.h
The following bug has been logged online: Bug reference: 3516 Logged by: Dirk Tilger Email address: [EMAIL PROTECTED] PostgreSQL version: 8.2.4 Operating system: Linux with Intel compiler on ia64 Description:Incomplete #ifdef statement in s_lock.h Details: I have been compiling postgresql 8.0, 8.1 and 8.2.4 with the Intel compiler in the past successfully. This time something went wrong and although I can't tell precisely how I triggered it, I have found a fix. We have an increasingly complex Makefile that compiles our third-party applications. While playing with the options of the compiler I must have activated something that triggered the #error on line 809 in file s_lock.h. I was able to fix the problem by changing line 81 of s_lock.h to: | #if defined(__GNUC__) || defined(__INTEL_COMPILER) || defined(__ICC) The icc 9.1.045 manual page says (reformatted): -8<- __ICC Value on IA-32 -- 910 Value on EM64T -- 910 Value on Itanium Architecture -- NA Notes -- Assigned value refers to the compiler (e.g., 800 is 8.00). Supported for legacy reasons. Use __INTEL_COMPILER instead. -8<- Best regards, Dirk Tilger PS: I'm not subscribed to the bugs list, put me in CC for communication. ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [BUGS] BUG #3516: Incomplete #ifdef statement in s_lock.h
"Dirk Tilger" <[EMAIL PROTECTED]> writes: > I was able to fix the problem by changing line 81 of s_lock.h to: > | #if defined(__GNUC__) || defined(__INTEL_COMPILER) || defined(__ICC) Hm. Some googling suggests that we should be using only __INTEL_COMPILER, not both. configure.in does it that way. regards, tom lane ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [BUGS] BUG #3516: Incomplete #ifdef statement in s_lock.h
"Dirk Tilger" <[EMAIL PROTECTED]> writes: > Operating system: Linux with Intel compiler on ia64 > I have been compiling postgresql 8.0, 8.1 and 8.2.4 with the Intel compiler > in the past successfully. This time something went wrong and although I > can't tell precisely how I triggered it, I have found a fix. BTW, what I found in googling suggested that (1) icc never has defined __ICC on 64-bit machines, and (2) although it does define __GNUC__ by default, there is a way to turn that off. So I surmise that your relevant change was adding a compiler flag that disabled the definition of __GNUC__. That doesn't seem to have stopped it from accepting GNU-style asm directives, though, so I kinda wonder what compiler behavior does change and what was the point of your flag change. This suggests that configure.in's check for icc is wrong/incomplete: it only tests if the compiler was previously determined to be gcc, ie, it defines __GNUC__. Now that we know that can be turned off in icc, it seems like we'd better check all the time. regards, tom lane ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
