Re: [BUGS] BUG #6729: Install of postgresql-devel for x86_84 and i686 fails
What about following:
%ifarch x86_64
%define PGLIBDIR lib64
%else
%define PGLIBDIR lib
%endif
In %install use /usr/pgsql-9.1/%{LIBDIR}/
same in %files
pg_config impacted ?
Thanks,
Yogesh Sharma
Devrim GÜNDÜZ wrote on 07/12/2012 01:42:56 PM:
>
> Hi,
>
> On Thu, 2012-07-12 at 16:36 -0400, Tom Lane wrote:
> > Devrim =?ISO-8859-1?Q?G=DCND=DCZ?= writes:
> > > It is not a bug, but it might be a missing feature (and I'm not sure
> > how
> > > to fix it :-) )
> >
> > It's fairly common for -devel packages of different architectures to
> > conflict. If you were to try to fix it, you'd likely need the 64-bit
> > versions to install their stuff into .../lib64/ not .../lib/.
>
> Well, there lies the problem. My packages push everything
> under /usr/pgsql-9.1 , and libs go to /usr/pgsql-9.1/lib. A
>
> > Not sure how practical such a change is at this late date.
>
> What if I build *9.2* with --libdir=/usr/pgsql-9.1/lib64 for x86_64, and
> then push 32-bit packages to /usr/pgsql-9.1/lib ?
>
Re: [BUGS] BUG #6729: Install of postgresql-devel for x86_84 and i686 fails
Hi Devrim, How things are going, long time since we exchanged any email. May be different lib folders can be used: /usr/pgsql-9.1/lib/libecpg.a /usr/pgsql-9.1/lib64/libecpg.a glibc-devel.i686 and glibc-devel.x86_64 does similar thing. rpm -ql glibc-devel.i686 |grep .a$ /usr/lib/libbsd-compat.a /usr/lib/libbsd.a /usr/lib/libc_nonshared.a /usr/lib/libg.a /usr/lib/libieee.a /usr/lib/libmcheck.a /usr/lib/libpthread_nonshared.a /usr/lib/librpcsvc.a rpm -ql glibc-devel.x86_64 |grep .a$ /usr/lib64/libbsd-compat.a /usr/lib64/libbsd.a /usr/lib64/libc_nonshared.a /usr/lib64/libg.a /usr/lib64/libieee.a /usr/lib64/libmcheck.a /usr/lib64/libpthread_nonshared.a /usr/lib64/librpcsvc.a It does affects pg_config as now pg_config has to be aware of x86_64 and i686 and provide right folder name. Thanks, Devrim GÜNDÜZ wrote on 07/12/2012 01:19:18 PM: > > Hi, > > It is not a bug, but it might be a missing feature (and I'm not sure how > to fix it :-) ) > > Regards, > > On Wed, 2012-07-11 at 23:16 +, ysha...@cymer.com wrote: > > The following bug has been logged on the website: > > > > Bug reference: 6729 > > Logged by: Yogesh Sharma > > Email address: ysha...@cymer.com > > PostgreSQL version: 9.1.4 > > Operating system: CentOS 6.3
Re: [BUGS] BUG #6733: All Tables Empty After pg_upgrade (PG 9.2.0 beta 2)
On Thu, Jul 12, 2012 at 05:21:31PM -0700, Mike Wilson wrote: > This can be closed. I figured out what I was doing wrong, which was > after the conversion I was cleaning up the old datadir by deleting it, > which destroyed the hard links to the data since I am using pg_upgrade > --link Uh, actually, a hard link has two directory entries pointing to the same file, so you can delete the old datadir and the new datadir should not be affected. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6733: All Tables Empty After pg_upgrade (PG 9.2.0 beta 2)
This can be closed. I figured out what I was doing wrong, which was after the conversion I was cleaning up the old datadir by deleting it, which destroyed the hard links to the data since I am using pg_upgrade --link Mike Wilson On Jul 12, 2012, at 3:49 PM, Bruce Momjian wrote: > On Thu, Jul 12, 2012 at 06:44:06PM -0400, Tom Lane wrote: >> mfwil...@gmail.com writes: >>> This runs without errors and I am able to start the new upgraded PG92beta2 >>> cluster. The schemas appear to be correct as well as the table definitions >>> and other schema objects. The tables themselves though are all empty. >> >> Hmm, maybe it's confused about XID past/future? Could we see the output >> of pg_controldata for both old and new clusters? > > Uh, I thought we only changfed the xlog stuff in 9.3, not 9.2, so I am > confused what would have changed in that area. > > -- > Bruce Momjian http://momjian.us > EnterpriseDB http://enterprisedb.com > > + It's impossible for everything to be true. + -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6732: Build issue when using gettext on FreeBSD 9
* Christian Ullrich wrote: I think I have a pretty good fix: Early in configure, see if the linker understands --no-copy-dt-needed-entries, or alternatively --no-add-needed (which is a deprecated name for the same thing). This is the "light" version of --as-needed: It does not discard unneeded libraries immediately, but ignores their dependencies. configure basically works as before, except that indirect dependencies cannot "hide" required libraries from it anymore. Oh, I should have made this clearer: This works without any modification to configure or anything else, so configure can still add --as-needed to the build LDFLAGS. -- Christian -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6732: Build issue when using gettext on FreeBSD 9
* Tom Lane wrote: ch...@chrullrich.net writes: Could we make the problem go away for you if we changed the order in which these libraries are probed for? That's a hack, surely, but it seems like one much less likely to break other working cases than any of the alternatives you suggest. To fix this specific issue, it would work to test gettext before Kerberos. On the other hand, the same thing is going to happen for every "downward" dependency (where a library higher up in configure depends on one tested later). I think I have a pretty good fix: Early in configure, see if the linker understands --no-copy-dt-needed-entries, or alternatively --no-add-needed (which is a deprecated name for the same thing). This is the "light" version of --as-needed: It does not discard unneeded libraries immediately, but ignores their dependencies. configure basically works as before, except that indirect dependencies cannot "hide" required libraries from it anymore. And a workaround specific to FreeBSD: There is a port for the current version of binutils (2.22), in which --no-copy-dt-needed-entries is the default. This can be done relatively easily, by first installing the binutils port and then installing Postgres with CFLAGS=-B/usr/local/bin . -- Christian -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6733: All Tables Empty After pg_upgrade (PG 9.2.0 beta 2)
On Thu, Jul 12, 2012 at 06:44:06PM -0400, Tom Lane wrote: > mfwil...@gmail.com writes: > > This runs without errors and I am able to start the new upgraded PG92beta2 > > cluster. The schemas appear to be correct as well as the table definitions > > and other schema objects. The tables themselves though are all empty. > > Hmm, maybe it's confused about XID past/future? Could we see the output > of pg_controldata for both old and new clusters? Uh, I thought we only changfed the xlog stuff in 9.3, not 9.2, so I am confused what would have changed in that area. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6733: All Tables Empty After pg_upgrade (PG 9.2.0 beta 2)
On Thu, Jul 12, 2012 at 10:16:18PM +, mfwil...@gmail.com wrote:
> The following bug has been logged on the website:
>
> Bug reference: 6733
> Logged by: Mike Wilson
> Email address: mfwil...@gmail.com
> PostgreSQL version: 9.1.4
> Operating system: Solaris 10
> Description:
>
> Filing this under PG914 since there isn't an option for PG9.2beta2.
> Possibly this should be filed elsewhere? If so apologies in advance.
>
> We are starting to prepare for the PG9.2 release so I have been performing
> some test pg_upgrades on our existing PG8.4.2 cluster. We have a sizable
> database and limited space so we have been testing upgrading our cluster
> using --link mode of pg_upgrade. After performing an upgrade though the new
> PG92 database has only empty tables.
>
> Running this:
> export NEWPG=/usr/postgres/postgresql-9.2.0_slony-2.1.1
> export OLDPG=/usr/postgres/pg842_slony210
>
> LD_LIBRARY_PATH=${NEWPG}/lib PATH=${NEWPG}/bin:${PATH} /usr/bin/time
> ${NEWPG}/bin/pg_upgrade --verbose --link \
> --old-datadir=/opt/postgres/db/root/old
> --new-datadir=/opt/postgres/db/root/new --old-bindir=${OLDPG}/bin/64/ \
> --new-bindir=${NEWPG}/bin/ --old-port=5432 --new-port=5920 --user=postgres
>
> This runs without errors and I am able to start the new upgraded PG92beta2
> cluster. The schemas appear to be correct as well as the table definitions
> and other schema objects. The tables themselves though are all empty. Not
> sure what is going on
OK, I just tested an upgrade from 9.1.4 to 9.2 HEAD and it worked just
fine using the regression database as content. The big question is what
is different about your setup. Can you check the data files in
/data/base/db_oid and see if they are all zero length in the new
cluster? A simple 'ls -l' should show it:
$ pwd
/u/pg/data/base/16413
$ ls -l
-rw--- 1 postgres postgres 122880 Jul 12 18:39 11744
-rw--- 1 postgres postgres 24576 Jul 12 18:39 11744_fsm
-rw--- 1 postgres postgres 8192 Jul 12 18:39 11744_vm
-rw--- 1 postgres postgres 16384 Jul 12 18:39 11746
-rw--- 1 postgres postgres 24576 Jul 12 18:39 11746_fsm
-
These should _not_ be all zeros. Please let me know what you find.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6733: All Tables Empty After pg_upgrade (PG 9.2.0 beta 2)
mfwil...@gmail.com writes: > This runs without errors and I am able to start the new upgraded PG92beta2 > cluster. The schemas appear to be correct as well as the table definitions > and other schema objects. The tables themselves though are all empty. Hmm, maybe it's confused about XID past/future? Could we see the output of pg_controldata for both old and new clusters? regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #6733: All Tables Empty After pg_upgrade (PG 9.2.0 beta 2)
The following bug has been logged on the website:
Bug reference: 6733
Logged by: Mike Wilson
Email address: mfwil...@gmail.com
PostgreSQL version: 9.1.4
Operating system: Solaris 10
Description:
Filing this under PG914 since there isn't an option for PG9.2beta2.
Possibly this should be filed elsewhere? If so apologies in advance.
We are starting to prepare for the PG9.2 release so I have been performing
some test pg_upgrades on our existing PG8.4.2 cluster. We have a sizable
database and limited space so we have been testing upgrading our cluster
using --link mode of pg_upgrade. After performing an upgrade though the new
PG92 database has only empty tables.
Running this:
export NEWPG=/usr/postgres/postgresql-9.2.0_slony-2.1.1
export OLDPG=/usr/postgres/pg842_slony210
LD_LIBRARY_PATH=${NEWPG}/lib PATH=${NEWPG}/bin:${PATH} /usr/bin/time
${NEWPG}/bin/pg_upgrade --verbose --link \
--old-datadir=/opt/postgres/db/root/old
--new-datadir=/opt/postgres/db/root/new --old-bindir=${OLDPG}/bin/64/ \
--new-bindir=${NEWPG}/bin/ --old-port=5432 --new-port=5920 --user=postgres
This runs without errors and I am able to start the new upgraded PG92beta2
cluster. The schemas appear to be correct as well as the table definitions
and other schema objects. The tables themselves though are all empty. Not
sure what is going on
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6729: Install of postgresql-devel for x86_84 and i686 fails
Hi, On Thu, 2012-07-12 at 16:36 -0400, Tom Lane wrote: > Devrim =?ISO-8859-1?Q?G=DCND=DCZ?= writes: > > It is not a bug, but it might be a missing feature (and I'm not sure > how > > to fix it :-) ) > > It's fairly common for -devel packages of different architectures to > conflict. If you were to try to fix it, you'd likely need the 64-bit > versions to install their stuff into .../lib64/ not .../lib/. Well, there lies the problem. My packages push everything under /usr/pgsql-9.1 , and libs go to /usr/pgsql-9.1/lib. A > Not sure how practical such a change is at this late date. What if I build *9.2* with --libdir=/usr/pgsql-9.1/lib64 for x86_64, and then push 32-bit packages to /usr/pgsql-9.1/lib ? Regards, -- Devrim GÜNDÜZ Principal Systems Engineer @ EnterpriseDB: http://www.enterprisedb.com PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer Community: devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr http://www.gunduz.org Twitter: http://twitter.com/devrimgunduz signature.asc Description: This is a digitally signed message part
Re: [BUGS] BUG #6729: Install of postgresql-devel for x86_84 and i686 fails
Devrim =?ISO-8859-1?Q?G=DCND=DCZ?= writes: > It is not a bug, but it might be a missing feature (and I'm not sure how > to fix it :-) ) It's fairly common for -devel packages of different architectures to conflict. If you were to try to fix it, you'd likely need the 64-bit versions to install their stuff into .../lib64/ not .../lib/. Not sure how practical such a change is at this late date. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6729: Install of postgresql-devel for x86_84 and i686 fails
Hi, It is not a bug, but it might be a missing feature (and I'm not sure how to fix it :-) ) Regards, On Wed, 2012-07-11 at 23:16 +, ysha...@cymer.com wrote: > The following bug has been logged on the website: > > Bug reference: 6729 > Logged by: Yogesh Sharma > Email address: ysha...@cymer.com > PostgreSQL version: 9.1.4 > Operating system: CentOS 6.3 > Description: > > For compilation of 64bit as well 32bit program I am trying to install both > versions. Here is error: > > > PackageArch Version > Repository > Size > > Installing: > postgresql91-devel i686 > 9.1.4-1PGDG.rhel6 > /postgresql91-devel-9.1.4-1PGDG.rhel6.i686 5.4 M > postgresql91-devel x86_64 > 9.1.4-1PGDG.rhel6 > /postgresql91-devel-9.1.4-1PGDG.rhel6.x86_64 6.2 M > > Transaction Summary > > Install 2 Package(s) > > Total size: 12 M > Installed size: 12 M > Is this ok [y/N]: y > Downloading Packages: > Running rpm_check_debug > Running Transaction Test > > > Transaction Check Error: > file /usr/pgsql-9.1/lib/libecpg.a conflicts between attempted installs of > postgresql91-devel-9.1.4-1PGDG.rhel6.x86_64 and > postgresql91-devel-9.1.4-1PGDG.rhel6.i686 > file /usr/pgsql-9.1/lib/libecpg_compat.a conflicts between attempted > installs of postgresql91-devel-9.1.4-1PGDG.rhel6.x86_64 and > postgresql91-devel-9.1.4-1PGDG.rhel6.i686 > file /usr/pgsql-9.1/lib/libpgport.a conflicts between attempted installs > of postgresql91-devel-9.1.4-1PGDG.rhel6.x86_64 and > postgresql91-devel-9.1.4-1PGDG.rhel6.i686 > file /usr/pgsql-9.1/lib/libpgtypes.a conflicts between attempted installs > of postgresql91-devel-9.1.4-1PGDG.rhel6.x86_64 and > postgresql91-devel-9.1.4-1PGDG.rhel6.i686 > file /usr/pgsql-9.1/lib/libpq.a conflicts between attempted installs of > postgresql91-devel-9.1.4-1PGDG.rhel6.x86_64 and > postgresql91-devel-9.1.4-1PGDG.rhel6.i686 > file /usr/pgsql-9.1/lib/pgxs/src/Makefile.global conflicts between > attempted installs of postgresql91-devel-9.1.4-1PGDG.rhel6.x86_64 and > postgresql91-devel-9.1.4-1PGDG.rhel6.i686 > > Error Summary > - > > > -- Devrim GÜNDÜZ Principal Systems Engineer @ EnterpriseDB: http://www.enterprisedb.com PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer Community: devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr http://www.gunduz.org Twitter: http://twitter.com/devrimgunduz signature.asc Description: This is a digitally signed message part
Re: [BUGS] BUG #6732: Build issue when using gettext on FreeBSD 9
ch...@chrullrich.net writes: > PostgreSQL 9.1 does not build on FreeBSD 9 if --enable-nls and a Heimdal > Kerberos build from ports is used. The build fails due to undefined > references to functions from gettext's libintl. Ugh. > Proposed workaround: Do not use --as-needed at all. Not really acceptable ... > Proposed fix: Use --as-needed during configure as well, or make its use > predicated on a working linker version (GNU ld 2.22 or later). ... and I'm not sure I like either of those either. The first seems likely to introduce as many problems as it fixes, and I don't see a reasonable way for the script to test whether --as-needed "works" (for a value of "works" that's rather unclear anyway). > ... configure therefore fails to detect libintl as required; the check > program links correctly because libintl is pulled in as an indirect > dependency via libgssapi. Could we make the problem go away for you if we changed the order in which these libraries are probed for? That's a hack, surely, but it seems like one much less likely to break other working cases than any of the alternatives you suggest. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #6732: Build issue when using gettext on FreeBSD 9
The following bug has been logged on the website: Bug reference: 6732 Logged by: Christian Ullrich Email address: ch...@chrullrich.net PostgreSQL version: 9.1.4 Operating system: FreeBSD 9 Description: PostgreSQL 9.1 does not build on FreeBSD 9 if --enable-nls and a Heimdal Kerberos build from ports is used. The build fails due to undefined references to functions from gettext's libintl. The reason is a combination of an oversight in PostgreSQL and the choice of system linker in FreeBSD 9, which is GNU ld 2.17.50. (It is nevertheless a PostgreSQL issue, not a FreeBSD one. Bear with me for a minute.) The PostgreSQL configure script indiscriminately enables the --as-needed option to the linker if the linker supports it, which GNU ld 2.17.50 in FreeBSD 9 does. It does not, however, use it in its own library checks. The configure script therefore fails to detect libintl as required; the check program links correctly because libintl is pulled in as an indirect dependency via libgssapi. There have been two relevant changes in the behavior of GNU ld since version 2.14, which was included in FreeBSD 8: - Version 2.15 added the --as-needed flag - Version 2.16 added the --add-needed flag (which was renamed to --copy-dt-needed-entries in 2.21 and had its default inverted in 2.22) With GNU ld 2.14 on FreeBSD 8, the build used to succeed because the dependency on libintl from libgssapi was sufficient. With the first change in behavior, the build with GNU ld 2.17 on FreeBSD 9 fails because the configuration check picks up libintl through libgssapi, but in the failing location (there are several, the first one to be hit is ecpg, but initdb is affected as well) libgssapi is dropped due to --as-needed and cannot contribute its dependency on libintl. With the current version, GNU ld 2.22, the build works again, because the second change in behavior allows the configure script to detect the need for libintl, which is then used wherever required. Proposed workaround: Do not use --as-needed at all. Proposed fix: Use --as-needed during configure as well, or make its use predicated on a working linker version (GNU ld 2.22 or later). -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #6729: Install of postgresql-devel for x86_84 and i686 fails
The following bug has been logged on the website: Bug reference: 6729 Logged by: Yogesh Sharma Email address: ysha...@cymer.com PostgreSQL version: 9.1.4 Operating system: CentOS 6.3 Description: For compilation of 64bit as well 32bit program I am trying to install both versions. Here is error: PackageArch Version Repository Size Installing: postgresql91-devel i686 9.1.4-1PGDG.rhel6 /postgresql91-devel-9.1.4-1PGDG.rhel6.i686 5.4 M postgresql91-devel x86_64 9.1.4-1PGDG.rhel6 /postgresql91-devel-9.1.4-1PGDG.rhel6.x86_64 6.2 M Transaction Summary Install 2 Package(s) Total size: 12 M Installed size: 12 M Is this ok [y/N]: y Downloading Packages: Running rpm_check_debug Running Transaction Test Transaction Check Error: file /usr/pgsql-9.1/lib/libecpg.a conflicts between attempted installs of postgresql91-devel-9.1.4-1PGDG.rhel6.x86_64 and postgresql91-devel-9.1.4-1PGDG.rhel6.i686 file /usr/pgsql-9.1/lib/libecpg_compat.a conflicts between attempted installs of postgresql91-devel-9.1.4-1PGDG.rhel6.x86_64 and postgresql91-devel-9.1.4-1PGDG.rhel6.i686 file /usr/pgsql-9.1/lib/libpgport.a conflicts between attempted installs of postgresql91-devel-9.1.4-1PGDG.rhel6.x86_64 and postgresql91-devel-9.1.4-1PGDG.rhel6.i686 file /usr/pgsql-9.1/lib/libpgtypes.a conflicts between attempted installs of postgresql91-devel-9.1.4-1PGDG.rhel6.x86_64 and postgresql91-devel-9.1.4-1PGDG.rhel6.i686 file /usr/pgsql-9.1/lib/libpq.a conflicts between attempted installs of postgresql91-devel-9.1.4-1PGDG.rhel6.x86_64 and postgresql91-devel-9.1.4-1PGDG.rhel6.i686 file /usr/pgsql-9.1/lib/pgxs/src/Makefile.global conflicts between attempted installs of postgresql91-devel-9.1.4-1PGDG.rhel6.x86_64 and postgresql91-devel-9.1.4-1PGDG.rhel6.i686 Error Summary - -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
