Re: [GENERAL] Access Problem After Version Upgrade -- FIXED
On Thu, 26 Jan 2006, Rich Shepard wrote: What do I do to trace the source of this problem and fix it? Thanks to Jim I found that libpq.so.3 were in the old directory. As soon as I moved them to /usr/lib (with libpq.so.4), SQL-Ledger allowed me to log in. All of this reminds me of the time, about 8 years ago, when postgres would install in one directory, but Red Hat's rpms put it in another directory. That caused all sorts of problems until I started building from source and ignoring the packages. Here, it was the move from /usr/local/pgsql to /var/lib/pgsql that caused me all this grief. A huge thank you to all of you -- and especially Jim. Rich -- Richard B. Shepard, Ph.D. | Author of Quantifying Environmental Applied Ecosystem Services, Inc. (TM) | Impact Assessments Using Fuzzy Logic http://www.appl-ecosys.com Voice: 503-667-4517 Fax: 503-667-8863 ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [GENERAL] Access Problem After Version Upgrade -- FIXED
Here, it was the move from /usr/local/pgsql to /var/lib/pgsql that caused me all this grief. A huge thank you to all of you -- and especially Jim. Although I am glad you were able to get up and running, typically you don't want to move libs like that. Instead update your /etc/ld.so.conf and run ldconfig. Sincerely, Joshua D. Drake Rich -- The PostgreSQL Company - Command Prompt, Inc. 1.503.667.4564 PostgreSQL Replication, Consulting, Custom Development, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/ ---(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: [GENERAL] Access Problem After Version Upgrade -- FIXED
On Thu, 26 Jan 2006, Joshua D. Drake wrote: Although I am glad you were able to get up and running, typically you don't want to move libs like that. Instead update your /etc/ld.so.conf and run ldconfig. True, Josh. What I'd prefer to do is remove /usr/local/pgsql/ once I know that nothing there is being used any more with the 8.x versions of postgres. I thought of making softlinks, but those would fail as soon as the directory tree was removed. Thanks, Rich -- Richard B. Shepard, Ph.D. | Author of Quantifying Environmental Applied Ecosystem Services, Inc. (TM) | Impact Assessments Using Fuzzy Logic http://www.appl-ecosys.com Voice: 503-667-4517 Fax: 503-667-8863 ---(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: [GENERAL] Access Problem After Version Upgrade -- FIXED
Rich Shepard [EMAIL PROTECTED] writes: On Thu, 26 Jan 2006, Joshua D. Drake wrote: Although I am glad you were able to get up and running, typically you don't want to move libs like that. Instead update your /etc/ld.so.conf and run ldconfig. True, Josh. What I'd prefer to do is remove /usr/local/pgsql/ once I know that nothing there is being used any more with the 8.x versions of postgres. I thought of making softlinks, but those would fail as soon as the directory tree was removed. FWIW, my practice when compiling PG from source (which I usually do) is as follows: * Configure each release with '--prefix=/usr/local/pgsql-8.1' (or whatever) * Create (as far as disk space permits) independent data directories for each version--e.g. '/var/lib/pgsql-8.1/data'. * Symlink whatever version I'm running to '/usr/local/pgsql'. Have the standard PATH contain '/usr/local/pgsql/bin'. This way, when I do an upgrade, I can test beforehand by setting PATH and LD_LIBRARY_PATH (if applicable) appropriately, migrating my data, running whatever programs I want to test, then switching the symlink. It's worked fairly well, and it's nice to have the old binaries and data directory sitting there to switch back to of something breaks horribly. The problem I've seen with RPM upgrades is that if something breaks in the data upgrade process, the old binaries are gone and it's a pain to get back to where you were. Putting locally-compiled software in /usr/bin or /usr/lib is a bad idea, generally, as you may confuse your package manager. -Doug ---(end of broadcast)--- TIP 6: explain analyze is your friend
