Обсуждение: Not quite there yet
I downloaded the new PostgreSQL 9.0 and it isn't quite there yet: -bash-3.2$ NEWDATADIR=`pwd` -bash-3.2$ OLDBINDIR=/usr/bin -bash-3.2$ NEWBINDIR=/opt/PostgreSQL/9.0/bin/ -bash-3.2$ pg_upgrade Performing Consistency Checks ----------------------------- Checking old data directory (/var/lib/pgsql/data) ok Checking old bin directory (/usr/bin) ok Checking new data directory (/opt/PostgreSQL/9.0/data) ok Checking new bin directory (/opt/PostgreSQL/9.0/bin) ok Checking for reg* system oid user data types ok Checking for /contrib/isn with bigint-passing mismatch ok Checking for large objects ok Creating catalog dump ok Checking for presence of required libraries fatal | Your installation references loadable libraries that are missing | from the new installation. You can add these libraries to | the new installation, or remove the functions using them | from the old installation. A list of the problem libraries | is in the file | "/opt/PostgreSQL/9.0/data/loadable_libraries.txt". -bash-3.2$ less /opt/PostgreSQL/9.0/data/loadable_libraries.txt Failed to load library: $libdir/plperl ERROR: could not load library "/opt/PostgreSQL/9.0/lib/postgresql/ plperl.so": libperl.so: cannot open shared object file: No such file or directory That means that the new version (EnterpriseDB binary installer) doesn't support plperl/plperlu . Unfortunately, I have functions written in plperl and plperlu. Playing with the new version will have to wait a bit. -- Mladen Gogala Sr. Oracle DBA 1500 Broadway New York, NY 10036 (212) 329-5251 www.vmsinfo.com
Mladen Gogala <mladen.gogala@vmsinfo.com> writes:
> -bash-3.2$ less /opt/PostgreSQL/9.0/data/loadable_libraries.txt
> Failed to load library: $libdir/plperl
> ERROR: could not load library "/opt/PostgreSQL/9.0/lib/postgresql/
> plperl.so": libperl.so: cannot open shared object file: No such file or
> directory
Apparently you don't have the same version of Perl as that installer
was built against, or you do but there's some rpath-ish issue preventing
plperl.so from finding it. On a Linux-like system, you might learn
something from
ldd /opt/PostgreSQL/9.0/lib/postgresql/plperl.so
regards, tom lane
Tom Lane wrote:
> Mladen Gogala <mladen.gogala@vmsinfo.com> writes:
>
>> -bash-3.2$ less /opt/PostgreSQL/9.0/data/loadable_libraries.txt
>> Failed to load library: $libdir/plperl
>> ERROR: could not load library "/opt/PostgreSQL/9.0/lib/postgresql/
>> plperl.so": libperl.so: cannot open shared object file: No such file or
>> directory
>>
>
> Apparently you don't have the same version of Perl as that installer
> was built against, or you do but there's some rpath-ish issue preventing
> plperl.so from finding it. On a Linux-like system, you might learn
> something from
> ldd /opt/PostgreSQL/9.0/lib/postgresql/plperl.so
>
> regards, tom lane
>
Here is the output of ldd, the libperl.so cannot be resolved:
**************************************************************************
[root@medo tmp]# ldd /opt/PostgreSQL/9.0/lib/postgresql/plperl.so
linux-gate.so.1 => (0x003cb000)
libperl.so => not found
libnsl.so.1 => /lib/libnsl.so.1 (0x00aa2000)
libdl.so.2 => /lib/libdl.so.2 (0x003d7000)
libm.so.6 => /lib/libm.so.6 (0x00ce5000)
libcrypt.so.1 => /lib/libcrypt.so.1 (0x00110000)
libutil.so.1 => /lib/libutil.so.1 (0x001c5000)
libpthread.so.0 => /lib/libpthread.so.0 (0x005b2000)
libc.so.6 => /lib/libc.so.6 (0x001e7000)
/lib/ld-linux.so.2 (0x00a1c000)
If I try the same thing with the plperl library from 8.4.4, it gives me
this:
**************************************************************************************
-bash-3.2$ ldd /usr/lib/pgsql/plperl.so
linux-gate.so.1 => (0x00d4d000)
libperl.so =>
/usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/libperl.so (0x00110000)
libresolv.so.2 => /lib/libresolv.so.2 (0x005ee000)
libnsl.so.1 => /lib/libnsl.so.1 (0x00ed4000)
libdl.so.2 => /lib/libdl.so.2 (0x00fcb000)
libm.so.6 => /lib/libm.so.6 (0x00639000)
libcrypt.so.1 => /lib/libcrypt.so.1 (0x004f6000)
libutil.so.1 => /lib/libutil.so.1 (0x00dc7000)
libpthread.so.0 => /lib/libpthread.so.0 (0x00c82000)
libc.so.6 => /lib/libc.so.6 (0x00242000)
/lib/ld-linux.so.2 (0x00a1c000)
*****************************************************************************
I tried with setting LD_LIBRARY_PATH to
/usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE, it didn't help much.
Now, there is a problem with unresolved symbols:
-bash-3.2$ less /opt/PostgreSQL/9.0/data/loadable_libraries.txt
Failed to load library: $libdir/plperl
ERROR: could not load library
"/opt/PostgreSQL/9.0/lib/postgresql/plperl.so":
/opt/PostgreSQL/9.0/lib/postgresql/plperl.so: undefined symbol:
boot_DynaLoader
Apparently, you're right, this is a version problem. This is a plain
vanilla CentOS 5.5 system. I can't just install the RPM packages because
my old database will be destroyed and I don't want that. Do you know
which system was this installer built on and which version of Perl does
it expect? Problem with the Red Hat system and its derivatives, like
CentOS, is that Postgres is installed on var/lib/pgsql, without regard
to the version string. That means that I can't just install the new RPM
packages because my /var/lib/pgsql/data would get overwritten and there
would be no old binaries. Building it from the source looks like the
only remaining option. I will try relinking just plperl, this binary
installer looks like it contains the full development package.
Unforunately, PgFoundry only contains sources for PgSQL 7 and 8, no
trace of the code for the version 9. That leads me to the conclusion
that I should wait a bit before upgrading any of my existing 8.4.4
databases to 9.0. Here is my OS version:
***********************************************************************************
-bash-3.2$ uname -a
Linux medo 2.6.18-194.11.4.el5PAE #1 SMP Tue Sep 21 05:48:23 EDT 2010
i686 athlon i386 GNU/Linux
-bash-3.2$ cat /etc/redhat-release
CentOS release 5.5 (Final)
-bash-3.2$
*******************************************************************************
I used this system to test at home because the vast majority of my
Postgres databases in the office are running on Red Hat 5.5 systems.
--
Mladen Gogala
Sr. Oracle DBA
1500 Broadway
New York, NY 10036
(212) 329-5251
www.vmsinfo.com
Mladen Gogala <mladen.gogala@vmsinfo.com> writes:
> Apparently, you're right, this is a version problem. This is a plain
> vanilla CentOS 5.5 system. I can't just install the RPM packages because
> my old database will be destroyed and I don't want that. Do you know
> which system was this installer built on and which version of Perl does
> it expect?
No, I don't :-(. You'd have to ask the EDB people that. I thought that
their download page documented which platforms they expect their
installer to work on, though.
regards, tom lane
Tom Lane wrote: > Mladen Gogala <mladen.gogala@vmsinfo.com> writes: > >> Apparently, you're right, this is a version problem. This is a plain >> vanilla CentOS 5.5 system. I can't just install the RPM packages because >> my old database will be destroyed and I don't want that. Do you know >> which system was this installer built on and which version of Perl does >> it expect? >> > > No, I don't :-(. You'd have to ask the EDB people that. I thought that > their download page documented which platforms they expect their > installer to work on, though. > > regards, tom lane > > I tried building it from the source, but pg_upgrade is not included in the source. I believe that this is really a RC2, rushed to production status for some reason. This is by no means a production quality release. -- Mladen Gogala Sr. Oracle DBA 1500 Broadway New York, NY 10036 (212) 329-5251 http://www.vmsinfo.com The Leader in Integrated Media Intelligence Solutions
On 10-09-27 11:44 AM, Mladen Gogala wrote: > Tom Lane wrote: >> Mladen Gogala <mladen.gogala@vmsinfo.com> writes: >>> Apparently, you're right, this is a version problem. This is a plain >>> vanilla CentOS 5.5 system. I can't just install the RPM packages >>> because my old database will be destroyed and I don't want that. Do >>> you know which system was this installer built on and which version >>> of Perl does it expect? >> >> No, I don't :-(. You'd have to ask the EDB people that. I thought that >> their download page documented which platforms they expect their >> installer to work on, though. >> >> regards, tom lane >> > I tried building it from the source, but pg_upgrade is not included in > the source. I believe that this is really a RC2, rushed to production > status for some reason. This is by no means a production quality release. > pg_upgrade comes with the 9.0 source, and is under contrib/ directory. -- Brad Nicholson 416-673-4106 Database Administrator, Afilias Canada Corp.
Mladen Gogala, 27.09.2010 17:44: >>> Apparently, you're right, this is a version problem. This is a >>> plain vanilla CentOS 5.5 system. I can't just install the RPM >>> packages because my old database will be destroyed and I don't >>> want that. Do you know which system was this installer built on >>> and which version of Perl does it expect? >> >> No, I don't :-(. You'd have to ask the EDB people that. I thought >> that their download page documented which platforms they expect >> their installer to work on, though. >> >> regards, tom lane >> > I tried building it from the source, but pg_upgrade is not included > in the source. pg_upgrade is an extra module (that's why it's listed in the "Additional Supplied Modules" chapter in the manual) and thusis not part of the core source distribution (if I'm not mistaken) http://pgfoundry.org/projects/pgupgrade Thomas
Brad Nicholson wrote: > > pg_upgrade comes with the 9.0 source, and is under contrib/ directory. > > Thanks. This was the missing peace. I was able to successfully upgrade the database cluster on my bleeding edge development machine. Unfortunately, this was compiled from source, no way that I will ever be allowed to pull out something like that with a production database. -- Mladen Gogala Sr. Oracle DBA 1500 Broadway New York, NY 10036 (212) 329-5251 http://www.vmsinfo.com The Leader in Integrated Media Intelligence Solutions
Thomas Kellerer wrote: > Mladen Gogala, 27.09.2010 17:44: > >>> Apparently, you're right, this is a version problem. This is a > >>> plain vanilla CentOS 5.5 system. I can't just install the RPM > >>> packages because my old database will be destroyed and I don't > >>> want that. Do you know which system was this installer built on > >>> and which version of Perl does it expect? > >> > >> No, I don't :-(. You'd have to ask the EDB people that. I thought > >> that their download page documented which platforms they expect > >> their installer to work on, though. > >> > >> regards, tom lane > >> > > I tried building it from the source, but pg_upgrade is not included > > in the source. > > pg_upgrade is an extra module (that's why it's listed in the "Additional Supplied Modules" chapter in the manual) and thusis not part of the core source distribution (if I'm not mistaken) > > http://pgfoundry.org/projects/pgupgrade No, that is some old release by someone else. pg_upgrade is in 9.0 contrib. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
Mladen Gogala wrote: > Brad Nicholson wrote: > > > > pg_upgrade comes with the 9.0 source, and is under contrib/ directory. > > > > > > Thanks. This was the missing peace. I was able to successfully upgrade > the database cluster on my bleeding edge development machine. > Unfortunately, this was compiled from source, no way that I will ever be > allowed to pull out something like that with a production database. You had to build what from source, the backend server or pg_upgrade? pg_upgrade should not need to be rebuilt and should be in the 9.0 installer. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
Bruce Momjian wrote: > Mladen Gogala wrote: > >> Brad Nicholson wrote: >> >>> pg_upgrade comes with the 9.0 source, and is under contrib/ directory. >>> >>> >>> >> Thanks. This was the missing peace. I was able to successfully upgrade >> the database cluster on my bleeding edge development machine. >> Unfortunately, this was compiled from source, no way that I will ever be >> allowed to pull out something like that with a production database. >> > > You had to build what from source, the backend server or pg_upgrade? > pg_upgrade should not need to be rebuilt and should be in the 9.0 > installer. > > Both the backend and the pg_update were built from source. I am now using RPM's and everybody is happy. -- Mladen Gogala Sr. Oracle DBA 1500 Broadway New York, NY 10036 (212) 329-5251 http://www.vmsinfo.com The Leader in Integrated Media Intelligence Solutions
Mladen Gogala wrote: > Bruce Momjian wrote: > > Mladen Gogala wrote: > > > >> Brad Nicholson wrote: > >> > >>> pg_upgrade comes with the 9.0 source, and is under contrib/ directory. > >>> > >>> > >>> > >> Thanks. This was the missing peace. I was able to successfully upgrade > >> the database cluster on my bleeding edge development machine. > >> Unfortunately, this was compiled from source, no way that I will ever be > >> allowed to pull out something like that with a production database. > >> > > > > You had to build what from source, the backend server or pg_upgrade? > > pg_upgrade should not need to be rebuilt and should be in the 9.0 > > installer. > > > > > Both the backend and the pg_update were built from source. I am now > using RPM's and everybody is happy. OK, good. Let me know if you have any other troubles. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +