RPMS for 7.1beta3 being uploaded.

Lamar Owen wrote:

Ok, I have a first set of 7.1beta3 RPMs uploading now.

... >

pgaccess currently will not run unless you reconfigure to use -i in the
startup. This is also being fixed in the RPMset -- there is a change necess
ary
in postgresql.config, I just have to do the change.

In my experience, pgaccess will use the Unix socket if the hostname is
left blank. Is this not the case with your RPMs?

--
Oliver Elphick Oliver.Elphick@lfix.co.uk
Isle of Wight http://www.lfix.co.uk/oliver
PGP: 1024R/32B8FAA1: 97 EA 1D 47 72 3F 28 47 6B 7E 39 CC 56 E4 C1 47
GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C
========================================
"For I know that my redeemer liveth, and that he shall
stand at the latter day upon the earth"
Job 19:25

Lamar Owen writes:

Ok, I have a first set of 7.1beta3 RPMs uploading now. These RPMs pass
regression on my home RedHat 6.2 machine, which has all locale environment
variables disabled (/etc/sysconfig/i18n deleted and a reboot).

Some thoughts:

Re: rpm-pgsql-7.1beta3.patch

| diff -uNr postgresql-7.1beta3.orig/src/Makefile.shlib postgresql-7.1beta3/src/Makefile.shlib
| --- postgresql-7.1beta3.orig/src/Makefile.shlib Wed Dec 6 14:37:08 2000
| +++ postgresql-7.1beta3/src/Makefile.shlib Mon Jan 15 01:50:04 2001
|@@ -160,7 +160,7 @@
|
| ifeq ($(PORTNAME), linux)
| shlib := lib$(NAME)$(DLSUFFIX).$(SO_MAJOR_VERSION).$(SO_MINOR_VERSION)
| - LINK.shared = $(COMPILER) -shared -Wl,-soname,$(soname)
| + LINK.shared = $(COMPILER) -shared -Wl
| endif

This cannot possibly be right.

| diff -uNr postgresql-7.1beta3.orig/src/Makefile.shlib~ postgresql-7.1beta3/src/Makefile.shlib~

???

| -#!/usr/local/bin/perl -w
| +#!/usr/bin/perl -w
(and more of these for Python)

I think this should be fixed to read

#! /usr/bin/env perl

Any comments?

Re: spec file

| # I hope this works....
|
| %ifarch ia64
| ln -s linux_i386 src/template/linux
| %endif

It definitely won't...

| # If libtool installed, copy some files....
| if [ -d /usr/share/libtool ]
| then
| cp /usr/share/libtool/config.* .
| fi

This is useless (because the config.* files are not in src/ anymore) and
(if it were fixed) not recommendable because config.{guess,sub} is not
compatible to itself, *especially* in terms of Linux recognition. You
really should use the ones PostgreSQL comes with.

| %ifarch ppc
| NEW_CFLAGS=`echo $CFLAGS|xargs -n 1|grep -v "\-O"|xargs -n 100`
| NEW_CFLAGS="$NEW_CFLAGS -O0"

This is no longer necessary.

| ./configure --enable-hba --enable-locale --with-CXX --prefix=/usr\

There is no option called '--enable-hba'. And I think you're supposed to
use %{configure}.

| %if %tkpkg
| --with-tk --with-x \
| %endif

There is no '--with-x'. '--with-tk' is the default if '--with-tcl' was
given; you should use '--without-tk' if you don't want it.

| %if %jdbc
| --with-java \
| %endif

There is no such option.

| %ifarch alpha
| --with-template=linux_alpha \
| %endif

This won't work and is not necessary.

| make COPT="$NEW_CFLAGS" DESTDIR=$RPM_BUILD_ROOT/usr all

You should set CFLAGS when you run configure. (%{configure} will do that.)
DESTDIR is only useful when you run 'make install'. And DESTDIR should
not include /usr.

| make all PGDOCS=unpacked -C doc

Not sure what this is supposed to do, but I don't think it will do what
you expect. The docs are installed automatically.

| mkdir -p $RPM_BUILD_ROOT/usr/{include/pgsql,lib,bin}
| mkdir -p $RPM_BUILD_ROOT%{_mandir}

You don't need that, the directories are made automatically.

| make DESTDIR=$RPM_BUILD_ROOT -C src install

No '-C src'.

| # copy over the includes needed for SPI development.
| pushd src/include
| /lib/cpp -M -I. -I../backend executor/spi.h | \
| xargs -n 1| \
| grep \\W| \
| grep -v ^/| \
| grep -v spi.o | \
| grep -v spi.h | \
| sort | \
| cpio -pdu $RPM_BUILD_ROOT/usr/include/pgsql

I think the standard installed set of headers is sufficient.

| %if %pgaccess
| # pgaccess installation

Pgaccess is installed automatically when you configure --with-tcl.

| # Move the PL's to the right place
| mv $RPM_BUILD_ROOT/usr/lib/pl*.so $RPM_BUILD_ROOT/usr/share/postgresql

You should not put architecture specific files into share/. I'm sure this
is in violation of FHS. (I'm amazed createlang finds it there.)

Re: sub-packages

* pg_id should be in server

* What were the last thoughts about renaming the <nothing> package to -clients?

* pg_upgrade won't work, so you might as well not install it. It will
probably be disabled before we release.

* You're missing pg_config in the -devel package.

These are the things I could find at first glance. ;-)

--
Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/

Peter Eisentraut wrote:

Lamar Owen writes:

Ok, I have a first set of 7.1beta3 RPMs uploading now. These RPMs pass
regression on my home RedHat 6.2 machine, which has all locale environment
variables disabled (/etc/sysconfig/i18n deleted and a reboot).

Some thoughts:

snip

| -#!/usr/local/bin/perl -w
| +#!/usr/bin/perl -w
(and more of these for Python)

I think this should be fixed to read

#! /usr/bin/env perl

Any comments?

What assurance do you have that 'env' is in /usr/bin? Linux FHS
(http://www.pathname.com/fhs/2.1/fhs-4.2.html) says that when perl
is in some location other than /usr/bin, then symlinks should be
provided to /usr/bin/perl. You don't have this assurance with
/usr/bin/env. Maybe there are some unices that do not have perl in
/usr/bin - but maybe there are unices that put 'env' into /bin
instead of /usr/bin. If you follow the current FHS, /usr/bin/perl
may be better -- but I'm not sure if that is entirely true of the
real world of linux boxes out there.

| # copy over the includes needed for SPI development.
| pushd src/include
| /lib/cpp -M -I. -I../backend executor/spi.h | \
| xargs -n 1| \
| grep \\W| \
| grep -v ^/| \
| grep -v spi.o | \
| grep -v spi.h | \
| sort | \
| cpio -pdu $RPM_BUILD_ROOT/usr/include/pgsql

I think the standard installed set of headers is sufficient.

I haven't installed the RPM yet. But I dissent unless things have
changed from 7.0 in that respect. I copmile against executor/spi.h,
based on the examples in the docs. Should I be using something else?
(I'll have to go look at the 7.1 source, but I just wanted to
register at least some comfusion, if not dissent)

--
Karl DeBisschop
kdebisschop@alert.infoplease.com
Learning Network Reference http://www.infoplease.com
Netsaint Plugin Developer
kdebisschop@users.sourceforge.net

(Sorry of this double posts - I'm having alias troubles on the
list.)

Peter Eisentraut wrote:

Lamar Owen writes:

Ok, I have a first set of 7.1beta3 RPMs uploading now. These RPMs pass
regression on my home RedHat 6.2 machine, which has all locale environment
variables disabled (/etc/sysconfig/i18n deleted and a reboot).

Some thoughts:

snip

| -#!/usr/local/bin/perl -w
| +#!/usr/bin/perl -w
(and more of these for Python)

I think this should be fixed to read

#! /usr/bin/env perl

Any comments?

What assurance do you have that 'env' is in /usr/bin? Linux FHS
(http://www.pathname.com/fhs/2.1/fhs-4.2.html) says that when perl
is in some location other than /usr/bin, then symlinks should be
provided to /usr/bin/perl. You don't have this assurance with
/usr/bin/env. Maybe there are some unices that do not have perl in
/usr/bin - but maybe there are unices that put 'env' into /bin
instead of /usr/bin. If you follow the current FHS, /usr/bin/perl
may be better -- but I'm not sure if that is entirely true of the
real world of linux boxes out there.

| # copy over the includes needed for SPI development.
| pushd src/include
| /lib/cpp -M -I. -I../backend executor/spi.h | \
| xargs -n 1| \
| grep \\W| \
| grep -v ^/| \
| grep -v spi.o | \
| grep -v spi.h | \
| sort | \
| cpio -pdu $RPM_BUILD_ROOT/usr/include/pgsql

I think the standard installed set of headers is sufficient.

I haven't installed the RPM yet. But I dissent unless things have
changed from 7.0 in that respect. I copmile against executor/spi.h,
based on the examples in the docs. Should I be using something else?
(I'll have to go look at the 7.1 source, but I just wanted to
register at least some comfusion, if not dissent)

--
Karl DeBisschop kdebisschop@alert.infoplease.com
Learning Network/Reference http://www.infoplease.com
Netsaint Plugin Developer kdebisschop@users.sourceforge.net

Peter Eisentraut wrote:

Lamar Owen writes:

Ok, I have a first set of 7.1beta3 RPMs uploading now. These RPMs pass
regression on my home RedHat 6.2 machine, which has all locale environment
variables disabled (/etc/sysconfig/i18n deleted and a reboot).

Some thoughts:

Re: rpm-pgsql-7.1beta3.patch

| diff -uNr postgresql-7.1beta3.orig/src/Makefile.shlib postgresql-7.1beta3/src/Makefile.shlib
| - LINK.shared = $(COMPILER) -shared -Wl,-soname,$(soname)
| + LINK.shared = $(COMPILER) -shared -Wl
| endif

This cannot possibly be right.

It's what you recommended a while back. See the discussions on -soname
from the libpq.so.2.1 versus libpq.so.2.0 thread awhile back.

| diff -uNr postgresql-7.1beta3.orig/src/Makefile.shlib~ postgresql-7.1beta3/src/Makefile.shlib~

???

Leftover Kedit baggage. Those are easy to forget to rm during patch
build, particularly at 2:00AM -- but there's no harm in it being there
for now. And it won't be there in -2.

| -#!/usr/local/bin/perl -w
| +#!/usr/bin/perl -w
(and more of these for Python)

I think this should be fixed to read

#! /usr/bin/env perl

No, for a RedHat or any other Linux distribution, /usr/bin is where perl
and python (or their symlinks) will always live.

Although you missed the redundant patches in the regression tree :-).

Re: spec file

| # I hope this works....
|
| %ifarch ia64
| ln -s linux_i386 src/template/linux
| %endif

It definitely won't...

7.0 required it. Baggage from the previous build.

| # If libtool installed, copy some files....
| if [ -d /usr/share/libtool ]
| then
| cp /usr/share/libtool/config.* .
| fi

This is useless (because the config.* files are not in src/ anymore) and
(if it were fixed) not recommendable because config.{guess,sub} is not
compatible to itself, *especially* in terms of Linux recognition. You
really should use the ones PostgreSQL comes with.

Trond can answer that one more effectively than can I, as that's his
insertion.

Of course, I've got to reorg the destination to match the source tree's
reorg.

| %ifarch ppc
| NEW_CFLAGS=`echo $CFLAGS|xargs -n 1|grep -v "\-O"|xargs -n 100`
| NEW_CFLAGS="$NEW_CFLAGS -O0"

This is no longer necessary.

Depends on the convolutions the particular build of rpm itself is
doing. This is a fix for the broken rpm setup found on Linux-PPC, as
found by Tom Lane. It would be marvelous if this would be expendable at
this juncture.

| ./configure --enable-hba --enable-locale --with-CXX --prefix=/usr\

There is no option called '--enable-hba'. And I think you're supposed to
use %{configure}.

If it works now, I'll use it. Version 7.0 and prior wouldn't work with
%{configure}.

And --enable-hba has existed at some point in time.

| %if %tkpkg
| --with-tk --with-x \
| %endif

There is no '--with-x'. '--with-tk' is the default if '--with-tcl' was
given; you should use '--without-tk' if you don't want it.

There was in the past a --with-x. So I need to change that to check for
the negation of tkpkg and use --without-tk if so.

| %if %jdbc
| --with-java \
| %endif

There is no such option.

Hmmm. I don't remember when that one got placed there....

| %ifarch alpha
| --with-template=linux_alpha \
| %endif

This won't work and is not necessary.

More 7.0 and prior baggage. The patches for alpha at one point (6.5
through 7.0.3) have required this -- of course, with the need for the
alpha patches gone, the need for the special config step is also gone.
One more piece of baggage I missed.

| make COPT="$NEW_CFLAGS" DESTDIR=$RPM_BUILD_ROOT/usr all

You should set CFLAGS when you run configure. (%{configure} will do that.)
DESTDIR is only useful when you run 'make install'. And DESTDIR should
not include /usr.

Yes, if you'll notice I fixed the DESTDIR in the install. But, of
course, it's not needed (nor is it used) in the build itself. Again,
I'll use %{configure} when I verify that it works properly (if it does,
that will be a very Good Thing for all involved). But, again, you're
seeing baggage that 7.0 and prior required in order to build (well,
except DESTDIR).

| make all PGDOCS=unpacked -C doc

Not sure what this is supposed to do, but I don't think it will do what
you expect. The docs are installed automatically.

Well, they are _now_. But 7.0 and prior..... again, more old baggage.

| mkdir -p $RPM_BUILD_ROOT/usr/{include/pgsql,lib,bin}
| mkdir -p $RPM_BUILD_ROOT%{_mandir}

You don't need that, the directories are made automatically.

They are _now_. But before, when the make install put things in the
'wrong' place, it was required to make the directories before doing the
copies and moves necessary.

| make DESTDIR=$RPM_BUILD_ROOT -C src install

No '-C src'.

Not anymore, at least. *sigh* There has been alot of baggage
accumulate in the spec due to 7.0 and prior's slightly brain-dead
build. I got rid of a lot of it -- but obviously I missed some.

| # copy over the includes needed for SPI development.
| pushd src/include
| /lib/cpp -M -I. -I../backend executor/spi.h | \
| xargs -n 1| \
| grep \\W| \
| grep -v ^/| \
| grep -v spi.o | \
| grep -v spi.h | \
| sort | \
| cpio -pdu $RPM_BUILD_ROOT/usr/include/pgsql

I think the standard installed set of headers is sufficient.

Is it? It _wasn't_ sufficient for SPI development at 7.0. Have the
headers and the headers install been fixed to install _all_ necessary
development headers, SPI included? If so, this step won't add any
headers anyway -- but it would be nice to see the difference.

| %if %pgaccess
| # pgaccess installation

Pgaccess is installed automatically when you configure --with-tcl.

It is now. It wasn't previously. At least not to the proper place.

| # Move the PL's to the right place
| mv $RPM_BUILD_ROOT/usr/lib/pl*.so $RPM_BUILD_ROOT/usr/share/postgresql

You should not put architecture specific files into share/. I'm sure this
is in violation of FHS. (I'm amazed createlang finds it there.)

It finds it there because I tell it to :-P. No, this objection is
definitely correct -- /usr/lib is the right place, and is where it will
live in the future. Previously, that line moved them to /usr/lib/pgsql.

Re: sub-packages

* pg_id should be in server

* What were the last thoughts about renaming the <nothing> package to -clients?

My thoughts are to leave it the way it is. I am not alone. But it's
not set in stone.

* pg_upgrade won't work, so you might as well not install it. It will
probably be disabled before we release.

Yes, this one needs to not be installed for this release.

* You're missing pg_config in the -devel package.

Yes, I am. I noticed that just after I uploaded the rpms from a 28.8
dialup at home. So, I'll be releasing a -2 set this week to fix that
problem, amongst others.

These are the things I could find at first glance. ;-)

Some first glance :-)....

Thanks for the feedback.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

On older versions of PG, 7.0 included, in the $PDGATA/base folder you
could see the names of the databases for that $PGDATA. Now all I see is:

$ ls -l
total 16
drwx------ 2 postgres wheel 1536 Jan 12 15:42 1
drwx------ 2 postgres wheel 1536 Jan 12 15:41 18719
drwx------ 2 postgres wheel 1536 Jan 12 15:42 18720
drwx------ 2 postgres wheel 1536 Jan 15 15:59 18721

Is there a way to relate this to the names of the databases? Why the
change? Or am I missing something key here..

- Brandon

b. palmer, bpalmer@crimelabs.net
pgp: www.crimelabs.net/bpalmer.pgp5

Lamar Owen <lamar.owen@wgcr.org> writes:

Peter Eisentraut wrote:

Lamar Owen writes:

Ok, I have a first set of 7.1beta3 RPMs uploading now. These RPMs pass
regression on my home RedHat 6.2 machine, which has all locale environment
variables disabled (/etc/sysconfig/i18n deleted and a reboot).

Some thoughts:

Re: rpm-pgsql-7.1beta3.patch

| diff -uNr postgresql-7.1beta3.orig/src/Makefile.shlib postgresql-7.1beta3/src/Makefile.shlib
| - LINK.shared = $(COMPILER) -shared -Wl,-soname,$(soname)
| + LINK.shared = $(COMPILER) -shared -Wl
| endif

This cannot possibly be right.

It's what you recommended a while back. See the discussions on -soname
from the libpq.so.2.1 versus libpq.so.2.0 thread awhile back.

Not having a soname doesn't really solve the problem, though... it
should be used, but correctly (major, minor)

Re: spec file

| # I hope this works....
|
| %ifarch ia64
| ln -s linux_i386 src/template/linux
| %endif

It definitely won't...

It did... we've successfully run queries etc on it.

| # If libtool installed, copy some files....
| if [ -d /usr/share/libtool ]
| then
| cp /usr/share/libtool/config.* .
| fi

This is useless (because the config.* files are not in src/ anymore) and
(if it were fixed) not recommendable because config.{guess,sub} is not
compatible to itself, *especially* in terms of Linux recognition. You
really should use the ones PostgreSQL comes with.

We have a libtool tuned to work with lots of platforms, like ia64,
s390 etc... this makes sure it's used.

--
Trond Eivind Glomsr�d
Red Hat, Inc.

bpalmer wrote:

On older versions of PG, 7.0 included, in the $PDGATA/base folder you
could see the names of the databases for that $PGDATA. Now all I see is:

No longer.

Is there a way to relate this to the names of the databases? Why the
change? Or am I missing something key here..

See the thread on the renaming in the archives. In short, this is part
of Vadim's work on WAL -- the new naming makes certain things easier for
WAL.

Utilities to relate the new names to the actual database/table names
_do_ need to be written, however. The information exists in one of the
system catalogs now -- it just has to be made accessible.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

Trond Eivind Glomsr�d wrote:

Lamar Owen <lamar.owen@wgcr.org> writes:

Peter Eisentraut wrote:

Re: rpm-pgsql-7.1beta3.patch
| diff -uNr postgresql-7.1beta3.orig/src/Makefile.shlib postgresql-7.1beta3/src/Makefile.shlib
| - LINK.shared = $(COMPILER) -shared -Wl,-soname,$(soname)
| + LINK.shared = $(COMPILER) -shared -Wl
| endif

This cannot possibly be right.

It's what you recommended a while back. See the discussions on -soname
from the libpq.so.2.1 versus libpq.so.2.0 thread awhile back.

Not having a soname doesn't really solve the problem, though... it
should be used, but correctly (major, minor)

Ok, what's your recommendation for the patch? I'll look again. 7.0.3-2
shipped with the equivalent patch. I think I know what you have in
mind, but it will be later tonight before I have time to try it.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

Lamar Owen <lamar.owen@wgcr.org> writes:

| %ifarch ppc
| NEW_CFLAGS=`echo $CFLAGS|xargs -n 1|grep -v "\-O"|xargs -n 100`
| NEW_CFLAGS="$NEW_CFLAGS -O0"

This is no longer necessary.

Depends on the convolutions the particular build of rpm itself is
doing. This is a fix for the broken rpm setup found on Linux-PPC, as
found by Tom Lane. It would be marvelous if this would be expendable at
this juncture.

It is. 7.1 builds cleanly on PPC without any CFLAGS hackery. I think
we can even survive the -fsigned-char stupidity now ;-)

I think the standard installed set of headers is sufficient.

Is it? It _wasn't_ sufficient for SPI development at 7.0. Have the
headers and the headers install been fixed to install _all_ necessary
development headers, SPI included?

No, nothing's been done about that AFAIK. I'm not sure the RPMs should
be taking it on themselves to solve the problem, however.

regards, tom lane

Tom Lane wrote:

Lamar Owen <lamar.owen@wgcr.org> writes:

doing. This is a fix for the broken rpm setup found on Linux-PPC, as
found by Tom Lane. It would be marvelous if this would be expendable at
this juncture.

It is. 7.1 builds cleanly on PPC without any CFLAGS hackery. I think
we can even survive the -fsigned-char stupidity now ;-)

Oh, good. Makes it much cleaner. Care to test that theory? :-)

I think the standard installed set of headers is sufficient.

Is it? It _wasn't_ sufficient for SPI development at 7.0. Have the
headers and the headers install been fixed to install _all_ necessary
development headers, SPI included?

No, nothing's been done about that AFAIK. I'm not sure the RPMs should
be taking it on themselves to solve the problem, however.

Just trying to make the postgresql-devel rpm complete, as per request.
Since the folk who build from source usually still have the source tree
around to do SPI development in, it's not as big of an issue for that
install.

Of course, if the consensus is that the RPM's simply track what the
source tarball does, then that can also be arranged. But, the precedent
of the RPMset fixing difficulties with the source install has already
been set with the upgrading procedure.

Arguments about why those wishing to do SPI development should install a
full source tree aside, I'm simply providing an RPM-specific requested
feature.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

Lamar Owen <lamar.owen@wgcr.org> writes:

It is. 7.1 builds cleanly on PPC without any CFLAGS hackery. I think
we can even survive the -fsigned-char stupidity now ;-)

Oh, good. Makes it much cleaner. Care to test that theory? :-)

I already did, I believe, but just in plain builds from source.

Let me know when you think the 7.1 RPM specfile is stable enough to be
worth testing, and I'll try to build PPC RPMs.

regards, tom lane

Tom Lane wrote:

Let me know when you think the 7.1 RPM specfile is stable enough to be
worth testing, and I'll try to build PPC RPMs.

Ok. Should be coincident with -2. I'm planning to have a -2 out later
this week.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

Is there a way to relate this to the names of the databases? Why the
change? Or am I missing something key here..

See the thread on the renaming in the archives. In short, this is part
of Vadim's work on WAL -- the new naming makes certain things easier for
WAL.

Utilities to relate the new names to the actual database/table names
_do_ need to be written, however. The information exists in one of the
system catalogs now -- it just has to be made accessible.

Yes, I am hoping to write this utility before 7.1 final. Maybe it will
have to be in /contrib.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Trond Eivind Glomsr�d writes:

We have a libtool tuned to work with lots of platforms, like ia64,
s390 etc... this makes sure it's used.

We don't use libtool. Nor does libtool care about the processor.

--
Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/

Peter Eisentraut <peter_e@gmx.net> writes:

Trond Eivind Glomsr�d writes:

We have a libtool tuned to work with lots of platforms, like ia64,
s390 etc... this makes sure it's used.

We don't use libtool.

Doing so would be a good thing.

Nor does libtool care about the processor.

As you can see from the actual code segment, only the
config.{guess,sub} files are copied.
--
Trond Eivind Glomsr�d
Red Hat, Inc.

Peter Eisentraut wrote:

The patch I recommended was

-  LDFLAGS_SL            := -Bdynamic -shared -soname $(shlib)
+  LDFLAGS_SL            := -Bdynamic -shared -soname lib$(NAME)$(DLSUFFIX).$(SO_MAJOR_VERSION)

And that is what was in 7.0.3.

but that's not what your patch does. The issue is fixed, you shouldn't
patch anything.

Oh, OK. Easy enough to delete that section and see where the chips
fall.

#! /usr/bin/env perl

No, for a RedHat or any other Linux distribution, /usr/bin is where perl
and python (or their symlinks) will always live.

I was thinking in terms of fixing this in the source tree.

Oh.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

Lamar Owen writes:

| diff -uNr postgresql-7.1beta3.orig/src/Makefile.shlib postgresql-7.1beta3/src/Makefile.shlib
| - LINK.shared = $(COMPILER) -shared -Wl,-soname,$(soname)
| + LINK.shared = $(COMPILER) -shared -Wl
| endif

This cannot possibly be right.

It's what you recommended a while back. See the discussions on -soname
from the libpq.so.2.1 versus libpq.so.2.0 thread awhile back.

The patch I recommended was

-  LDFLAGS_SL            := -Bdynamic -shared -soname $(shlib)
+  LDFLAGS_SL            := -Bdynamic -shared -soname lib$(NAME)$(DLSUFFIX).$(SO_MAJOR_VERSION)

but that's not what your patch does. The issue is fixed, you shouldn't
patch anything.

I think this should be fixed to read

#! /usr/bin/env perl

No, for a RedHat or any other Linux distribution, /usr/bin is where perl
and python (or their symlinks) will always live.

I was thinking in terms of fixing this in the source tree.

There is no '--with-x'. '--with-tk' is the default if '--with-tcl' was
given; you should use '--without-tk' if you don't want it.

There was in the past a --with-x.

But it never did anything.

--
Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/

Peter Eisentraut wrote:

Trond Eivind Glomsr�d writes:

We have a libtool tuned to work with lots of platforms, like ia64,
s390 etc... this makes sure it's used.

We don't use libtool. Nor does libtool care about the processor.

'We' has a lot of different meanings. In your sentence, of course, 'We'
is 'the PostgreSQL Global Development Group.' In my case, I have to use
a 'We' comprised of the PGDG, RedHat, SuSE, TurboLinux, Mandrake,
Caldera, GreatBridge, etc.

The RPM-based Linux distributions have their own consistency
requirements that may at times conflict with 'our' own. In the case of
packages the are being distributed with these distributions, it behooves
'us' to play by the distribution's rules when those rules don't
negatively affect 'our' primary source distribution.

By having this only in the RPM spec file, it obviates the need for 'us'
to change anything, and it allows 'our' package to be more easily
integrated in the distribution in question.

In particular, this was and is a RedHat-made change. It does not break
anything that I am aware of, and allows the distributions to do their
thing as well.

Therefore, the conditional. If the distribution doesn't care, then the
files won't exist, and they won't overwrite ours. RedHat 6.1, for
instance.

Is there a technical reason that this would cause a failed or even
non-optimal build? Non-functional binaries? Problems at the user
level?

The PPC shenanigans will be gone -- but the libtool stuff -- until
libtoolize works properly on 'our' build (I seem to recall a
distribution that successfully libtollized PostgreSQL -- I'll have to
check.....), this seems reasonable to me in my limited knowledge.

So, Trond, what sort of tunings have been performed that make the files
in question need to be copied? I'm sure you have a good reason; I am
just curious as to what it is.

Likewise, Peter, I'm sure that from your point of view you have good
reasons -- I'd like to see them as well, for the same reasons as I'd
like to see Trond's.

We're early in the RPM beta cycle here -- many things can and will
change before final.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

Peter Eisentraut <peter_e@gmx.net> writes:

Trond Eivind Glomsr�d writes:

We don't use libtool.

Doing so would be a good thing.

Not if our code is more portable than libtool's.

And this is the case? libtool covers pretty much everything... and you
don't need to use it for every target.

Nor does libtool care about the processor.

As you can see from the actual code segment, only the
config.{guess,sub} files are copied.

But you argued that this is because your config.guess supports s390 and
ia64 (which ours does as well)

It may do so now, but I'm pretty sure it hasn't always done so... and
even if it does, it doesn't hurt.

--
Trond Eivind Glomsr�d
Red Hat, Inc.

Trond Eivind Glomsr�d writes:

We don't use libtool.

Doing so would be a good thing.

Not if our code is more portable than libtool's.

Nor does libtool care about the processor.

As you can see from the actual code segment, only the
config.{guess,sub} files are copied.

But you argued that this is because your config.guess supports s390 and
ia64 (which ours does as well), but that cannot possibly be libtool
related.

--
Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/

Lamar Owen <lamar.owen@wgcr.org> writes:

Peter Eisentraut wrote:

Trond Eivind Glomsr�d writes:

We have a libtool tuned to work with lots of platforms, like ia64,
s390 etc... this makes sure it's used.

We don't use libtool. Nor does libtool care about the processor.

In particular, this was and is a RedHat-made change. It does not break
anything that I am aware of, and allows the distributions to do their
thing as well.

Note that this wasn't included in Red Hat Linux 7... it's been done
since then, and I don't remember doing it myself (which of course
doesn't mean I didn't do it :) - it might have been done for the S/390
port, by the people working on that.

So, Trond, what sort of tunings have been performed that make the files
in question need to be copied? I'm sure you have a good reason; I am
just curious as to what it is.

For most apps, it's just a question of configure working vs. configure
failing on IA64 (there is no "tuning" as such, my choice of words
wasn't too good). There may be something similar for S/390.

--
Trond Eivind Glomsr�d
Red Hat, Inc.

Trond Eivind Glomsr�d wrote:

Lamar Owen <lamar.owen@wgcr.org> writes:

In particular, this was and is a RedHat-made change. It does not break
anything that I am aware of, and allows the distributions to do their
thing as well.

Note that this wasn't included in Red Hat Linux 7... it's been done
since then, and I don't remember doing it myself (which of course
doesn't mean I didn't do it :) - it might have been done for the S/390
port, by the people working on that.

A non-conditional version (the conditional is my change) was included as
far back as RedHat 6.2.

For most apps, it's just a question of configure working vs. configure
failing on IA64 (there is no "tuning" as such, my choice of words
wasn't too good). There may be something similar for S/390.

Can we test both ways (after your current project is done)?
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

Lamar Owen writes:

Likewise, Peter, I'm sure that from your point of view you have good
reasons -- I'd like to see them as well, for the same reasons as I'd
like to see Trond's.

Two points of view here:

1. The config.* files were specifically updated because the old ones did
not recognize certain Linux(!) setups correctly. This probably affects
all config.*'s before August 2000. This will simply cause the build to
fail.

2. If you use the %{configure} macro then this will be pointless because
that macro selects the host system type itself:

| %configure \
| CFLAGS="${CFLAGS:-%optflags}" ; export CFLAGS ; \
| CXXFLAGS="${CXXFLAGS:-%optflags}" ; export CXXFLAGS ; \
| FFLAGS="${FFLAGS:-%optflags}" ; export FFLAGS ; \
| %{?__libtoolize:[ -f configure.in ] && %{__libtoolize} --copy --force} ; \
| ./configure %{_target_platform} \\\
...

(This is subtly wrong as well, but that's something for the RPM folks to
deal with.)

So in short, don't do it.

--
Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/

Wow, this looks great, and it worked the first time too. I will commit
if no one makes objects.

Is there a way to relate this to the names of the databases? Why the
change? Or am I missing something key here..

See the thread on the renaming in the archives. In short, this is part
of Vadim's work on WAL -- the new naming makes certain things easier for
WAL.

Utilities to relate the new names to the actual database/table names
_do_ need to be written, however. The information exists in one of the
system catalogs now -- it just has to be made accessible.

Yes, I am hoping to write this utility before 7.1 final. Maybe it will
have to be in /contrib.

I just finished writing such an app. Take a look. It's in a format
that can be put in /contrib. Let me know if you want any changes made,
etc. Feel free to use any of the code you wish.

http://www.crimelabs.net/postgresql.shtml

- Brandon

b. palmer, bpalmer@crimelabs.net
pgp: www.crimelabs.net/bpalmer.pgp5

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

On Wed, Jan 17, 2001 at 05:49:36PM -0500, Bruce Momjian wrote:

Wow, this looks great, and it worked the first time too. I will commit
if no one makes objects.

I object. The code displays oids and tablenames or relnames. Oid is just
the initial, default filename for tables, and may change to something other
than the oid. Currently, the reindex code is the only place that could change
the relfilenode without changing the oid, but I think there may be more
in the future.

Here's a patch to Brandon's code (completely untested, BTW):

Ross

*** oid2name.c.orig	Wed Jan 17 17:12:05 2001
--- oid2name.c	Wed Jan 17 17:27:11 2001
***************
*** 331,339 ****
  
    /* don't exclude the systables if this is set */
    if(systables == 1)
!     sprintf(todo, "select oid,relname from pg_class order by relname");
    else
!     sprintf(todo, "select oid,relname from pg_class where relname not like 'pg_%%' order by relname");
  
    sql_exec(conn, todo, NULL);
  }
--- 331,339 ----
  
    /* don't exclude the systables if this is set */
    if(systables == 1)
!     sprintf(todo, "select relfilenode,relname from pg_class order by relname");
    else
!     sprintf(todo, "select relfilenode,relname from pg_class where relname not like 'pg_%%' order by relname");
  
    sql_exec(conn, todo, NULL);
  }
***************
*** 348,354 ****
    todo = (char *) malloc (1024);
  
    /* get the oid and tablename where the name matches tablename */
!   sprintf(todo, "select oid,relname from pg_class where relname = '%s'", tablename);
  
    returnvalue = sql_exec(conn, todo, 1);
  
--- 348,354 ----
    todo = (char *) malloc (1024);
  
    /* get the oid and tablename where the name matches tablename */
!   sprintf(todo, "select relfilenode,relname from pg_class where relname = '%s'", tablename);
  
    returnvalue = sql_exec(conn, todo, 1);
  
***************
*** 372,378 ****
  
    todo = (char *) malloc (1024);
  
!   sprintf(todo, "select oid,relname from pg_class where oid = %i", oid);
  
    returnvalue = sql_exec(conn, todo, 1);
  
--- 372,378 ----
  
    todo = (char *) malloc (1024);
  
!   sprintf(todo, "select relfilenode,relname from pg_class where relfilenode = %i", oid);
  
    returnvalue = sql_exec(conn, todo, 1);
  

I object. The code displays oids and tablenames or relnames. Oid is just
the initial, default filename for tables, and may change to something other
than the oid. Currently, the reindex code is the only place that could change
the relfilenode without changing the oid, but I think there may be more
in the future.

Looks great, and I agree. Did not know that little piece of information.
I have made the changed to my code, here's the new version. I have
tested this one and updated the web page.

- brandon

b. palmer, bpalmer@crimelabs.net
pgp: www.crimelabs.net/bpalmer.pgp5

"Ross J. Reedstrom" <reedstrm@rice.edu> writes:

I object. The code displays oids and tablenames or relnames. Oid is just
the initial, default filename for tables, and may change to something other
than the oid. Currently, the reindex code is the only place that could change
the relfilenode without changing the oid, but I think there may be more
in the future.

Right, relfilenode is the thing to look at, not OID. I believe we are
thinking of using relfilenode updates for a number of things in the
future --- CLUSTER and faster index rebuilds in VACUUM are two thoughts
that come to mind ...

regards, tom lane

I have added this to /contrib for 7.1.

I object. The code displays oids and tablenames or relnames. Oid is just
the initial, default filename for tables, and may change to something other
than the oid. Currently, the reindex code is the only place that could change
the relfilenode without changing the oid, but I think there may be more
in the future.

Looks great, and I agree. Did not know that little piece of information.
I have made the changed to my code, here's the new version. I have
tested this one and updated the web page.

- brandon

b. palmer, bpalmer@crimelabs.net
pgp: www.crimelabs.net/bpalmer.pgp5

Content-Description:

[ Attachment, skipping... ]

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

What I will probably do is make a wrapper around it so it I can do:

ls | oidmapper

and see the files as table names.

Hmmm.... I think I can add that to the code..

will try..

It has to be pretty smart. Consider this:

$ pwd
/u/pg/data/base/18720
$ ls -l

It has to read the directories above, looking for a directory name that
is all numbers. It needs to then use that to find the database name.
Of course, if you are not in the directory, you may have a problem with
the database and require them to specify it on the command line.

It then has to process the the contents of ls -l and find the oids in
there and map them:

total 2083
-rw------- 1 postgres postgres 8192 Jan 15 23:43 1215
-rw------- 1 postgres postgres 8192 Jan 15 23:43 1216
-rw------- 1 postgres postgres 8192 Jan 15 23:43 1219
-rw------- 1 postgres postgres 24576 Jan 15 23:43 1247
-rw------- 1 postgres postgres 114688 Jan 19 21:43 1249
-rw------- 1 postgres postgres 229376 Jan 15 23:43 1255
-rw------- 1 postgres postgres 24576 Jan 15 23:59 1259
-rw------- 1 postgres postgres 8192 Jan 15 23:43 16567
-rw------- 1 postgres postgres 16384 Jan 16 00:04 16579

The numbers <16k are system tables so you probably need code to lookup
stuff <16k, and if it doesn't begin with pg_, it is not an oid.

It also should handle 'du':

$ du
1517 ./1
1517 ./18719
2085 ./18720
1517 ./27592
20561 ./27593
27198 .

As you can see, this could be tricky.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

On Tue, 23 Jan 2001, Bruce Momjian wrote:

I have added this to /contrib for 7.1.

Not sure if you know this, but you checked in the code compiled and w/
the .o file...

FYI.

b. palmer, bpalmer@crimelabs.net
pgp: www.crimelabs.net/bpalmer.pgp5

Thanks. Removed.

On Tue, 23 Jan 2001, Bruce Momjian wrote:

I have added this to /contrib for 7.1.

Not sure if you know this, but you checked in the code compiled and w/
the .o file...

FYI.

b. palmer, bpalmer@crimelabs.net
pgp: www.crimelabs.net/bpalmer.pgp5

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026