Thread: \d* won't work in 7.0.2?
Dear PostgreSQL people, I'm baffled at this: \d (and friends) won't give me the definition of a table, view, function, etc: $ initdb /var/lib/pgsql ...stuff... $ psql template1 Welcome to psql, the PostgreSQL interactive terminal. ...stuff... template1=# \dS List of relations Name | Type | Owner ----------------+---------+----------pg_aggregate | table | postgrespg_am | table | postgrespg_amop | table | postgrespg_amproc | table | postgres ...stuff... template1=# \d pg_am ERROR: getattproperties: no attribute tuple 1259 -2 template1=# create table test (id int, val int); CREATE template1=# \dt List of relationsName | Type | Owner ------+-------+----------test | table | mgiovann (1 row) template1=# \d test ERROR: getattproperties: no attribute tuple 1259 -2 template1=# \da ERROR: getattproperties: no attribute tuple 1247 -2 template1=# \dd ERROR: get_attdisbursion: no attribute tuple 16932 -2 template1=# \q $ The system I'm using is a fresh installation of the 7.0.2-2.ppc.rpm's on an MkLinux DR3 running on a PowerMac 8100/80. More specifically: * No exported shell variables were set, the location of pgsql files (bin, lib, database) and directories is exactly as the distribution expects: /var/lib/pgsql * No command line options were set, a simple "postmaster -D /var/lib/pgsql" command was issued. * Installation was, basically, "rpm -i postgresql*" * "createuser mgiovann" was executed, with create database/user permissions. * Version is:PostgreSQL 7.0.2 on powerpc-iso-8859-1-linux-gnu, compiled by gcc 2.95.2 * I've installed from the PPC RPM's, version 7.0.2-2 (found in ftp://ftp.postgresql.org//pub/binary/v7.0.2/redhat-RPM/RPMS/PPC/ as of today). * Platform info:PowerMac 8100/80, PowerPC 601/80MHz/32MB RAM $ cat /proc/cpuinfo processor : 0 cpu : 601 revision : 0.1 bogomips : 78.85 machine : PowerMac $ cat /proc/meminfo total: used: free: shared: buffers: cached: Mem: 33554432 27328512 6225920 0 1118208 7114752 Swap: 83881984 651264 83230720 MemTotal: 32768 kB MemFree: 6080 kB MemShared: 0 kB Buffers: 1092 kB Cached: 6948 kB SwapTotal: 81916 kB SwapFree: 81280 kB $ cat /proc/version Linux version 2.0.37-osfmach3 (root@build.mklinux.org) (gcc version egcs-2.91.6619990314 (egcs-1.1.2 release)) GENERIC_08alpha-20Fri Jul 30 11:07:38 PDT 1999 $ gcc -v Reading specs from /usr/lib/gcc-lib/ppc-redhat-linux/2.95.2/specs gcc version 2.95.2 19990906 (prerelease) Please note, I *did not* compile PostgreSQL myself. I've tried grepping the documentation for something along the lines of "getattproperties", or "\d", but I could find nothing relevant to my problem. I sincerely hope it's not something stupid I did, the last thing I'd want is to waste your time. If that's the case, please accept my apologies in advance. Thank you, and best regards, Matías Giovannini Script S.A. +5411-4325-6546 matias@k-bell.com -- Microsoft shouldn't be broken up. It should be shut down. -- Phil Agre
Matías Giovannini <matias@k-bell.com> writes:
> I'm baffled at this: \d (and friends) won't give me the definition of a
> table, view, function, etc:
Wow, that's pretty broken. I assure you \d works for everyone else ;-).
I think you must be looking at a serious configuration mistake or
portability problem.
> * Version is:
> PostgreSQL 7.0.2 on powerpc-iso-8859-1-linux-gnu, compiled by gcc 2.95.2
> * I've installed from the PPC RPM's, version 7.0.2-2 (found in
> ftp://ftp.postgresql.org//pub/binary/v7.0.2/redhat-RPM/RPMS/PPC/ as of today).
Can anyone else check these same RPMs? I have a nasty feeling that they
might have been miscompiled (eg, built with optimization level higher than
will work given the old fmgr).
regards, tom lane
Tom Lane wrote: > > Matías Giovannini <matias@k-bell.com> writes: > > I'm baffled at this: \d (and friends) won't give me the definition of a > > table, view, function, etc: > > Wow, that's pretty broken. I assure you \d works for everyone else ;-). > I think you must be looking at a serious configuration mistake or > portability problem. > > > * Version is: > > PostgreSQL 7.0.2 on powerpc-iso-8859-1-linux-gnu, compiled by gcc 2.95.2 > > * I've installed from the PPC RPM's, version 7.0.2-2 (found in > > ftp://ftp.postgresql.org//pub/binary/v7.0.2/redhat-RPM/RPMS/PPC/ as of today). > > Can anyone else check these same RPMs? I have a nasty feeling that they > might have been miscompiled (eg, built with optimization level higher than > will work given the old fmgr). > > regards, tom lane Yes, it seems to be a configuration problem. I rebuilt PostgreSQL 7.0.2 from sources (postgresql.tar.gz), installed it and it works just fine. Unfortunately, I don't even know how to start to make binary RPMs, so I can't be of much help here. I'd love to help, but I'm afraid I will need some coaching; if anybody could give me a couple of pointers, I can study and give it a try. Best regards, Matías. -- Microsoft shouldn't be broken up. It should be shut down. -- Phil Agre
Matías Giovannini wrote:
> Tom Lane wrote:
> > Can anyone else check these same RPMs? I have a nasty feeling that they
> > might have been miscompiled (eg, built with optimization level higher than
> Unfortunately, I don't even know how to start to make binary RPMs, so I
> can't be of much help here. I'd love to help, but I'm afraid I will need
> some coaching; if anybody could give me a couple of pointers, I can
> study and give it a try.
First, what optimization level is too high on PPC for the old fmgr?
Second, to rebuild binary RPM's, do the following:
1.) Download the source RPM
(ftp.postgresql.org/pub/binary/v7.0.2/RPM/SRPMS/postgresql-7.0.2-2.src.rpm)
2.) Install the source RPM (as root, unless you have a normal user RPM
set-up, which if you've never built the RPM's before, you won't) -- rpm
-i postgresql-7.0.2-2.src.rpm
3.) Find the RPM build dir: on my RedHat box it is /usr/src/redhat, on
Mandrake, it is /usr/src/RPM -- you can find this yourself by issuing
the command rpm --showrc|grep '^-14: _topdir' -- on my box it gives
topdir as being %{_usrsrc}/redhat -- and _usrsrc is almost always
/usr/src.
4.) CD to _topdir. Then cd to SPECS
5.) Open postgresql.spec in your favorite editor, and find the line
defining CFLAGS (currently defines CFLAGS as $RPM_OPT_FLAGS), and add
the correct optimization switches. Save postgresql.spec and close.
6.) With CWD as _topdir/SPECS, execute the following:
rpm -ba postgresql.spec >postgresql-build.log 2>&1 & tail -f
postgresql-build.log
7.) The build will progress, and a log will be kept. Once the build has
stopped (indicated by several lines showing that .ppc.rpm files are
being written), interrupt out of the tail -f.
8.) You'll find the binary RPM's in
_topdir/RPMS/_arch/postgresql*._arch.rpm -- where _arch is your
architecture, in this case, ppc.
9.) Backup your data, make sure you have the original RPM's to go back
to, and execute rpm -Uvh for each rpm you have installed.
I'm copying Murray Todd Williams on this, as he did the binary rebuild
of my source RPM for PowerPC. It is possible that his machine's
$RPM_OPT_FLAGS is set to an excessively high optimization for PostgreSQL
7.0. If this is the case, I'll need to coordinate with him on a -3
RPMset, which, due to some other problems with the -2 set, is overdue
anyway from me. :-(
HTH
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11
Lamar Owen <lamar.owen@wgcr.org> writes:
> First, what optimization level is too high on PPC for the old fmgr?
Anything higher than -O0, probably :-(.
BTW, I would like to get confirmation from someone with a PPC that the
new fmgr code works with normal optimization levels on PPC. If you
want to try it, grab the current nightly snapshot tarball or current
CVS sources and see if the system will pass regression tests...
regards, tom lane
Tom Lane wrote: > > Lamar Owen <lamar.owen@wgcr.org> writes: > > First, what optimization level is too high on PPC for the old fmgr? > > Anything higher than -O0, probably :-(. > > BTW, I would like to get confirmation from someone with a PPC that the > new fmgr code works with normal optimization levels on PPC. If you > want to try it, grab the current nightly snapshot tarball or current > CVS sources and see if the system will pass regression tests... > > regards, tom lane Will do. Should I tweak the configure to thrust the optlevel up, or just do a compile and parallel regression with the default build options? I'm getting the tarballs now. Regards, Matías.
Matías Giovannini <matias@k-bell.com> writes:
>> BTW, I would like to get confirmation from someone with a PPC that the
>> new fmgr code works with normal optimization levels on PPC. If you
>> want to try it, grab the current nightly snapshot tarball or current
>> CVS sources and see if the system will pass regression tests...
> Will do. Should I tweak the configure to thrust the optlevel up, or just
> do a compile and parallel regression with the default build options?
Check the src/template file for your platform to see what the default
CFLAGS are. I think we took out the -O0 that was there before, but
I don't know what it says now.
Might as well go for broke and try it with max optimization, whatever
that is on your compiler...
regards, tom lane