Thread: moving an installation
I need to be able to build postgres (7.4.3) with a given --prefix, but then pack up the installation directory and deploy it in another directory (as part of a product install, for instance). I configured with --disable-rpath, but I'm still getting the creating conversions... ERROR: could not access file "$libdir/ascii_and_mic": No such file or directory error when I try to run initdb from the new location. This is on Solaris 9, and I've verified that my LD_LIBRARY_PATH includes the postgres/lib dir in the new location. Is there a way I can get around this at runtime? I was under the impression that --disable-rpath prevented library paths from being compiled into the code, but maybe this "$libdir" is a different thing? Thanks in advance for any help. - DAP ====================================================== David Parker Tazz Networks (401) 709-5130
OK, I see the problem is in the share/conversion_create.sql script, which references $libdir as part of the library path. So modifying the script and replacing $libdir with an actual path fixes the problem, allowing initdb to run. But is there any way around this without actually modifying the script? e.g., an environment variable or something? (setting the "libdir" env var doesn't seem to do it). Thanks. - DAP -----Original Message----- From: pgsql-general-owner@postgresql.org [mailto:pgsql-general-owner@postgresql.org] On Behalf Of David Parker Sent: Thursday, July 15, 2004 4:05 PM To: pgsql-general@postgresql.org Subject: [GENERAL] moving an installation I need to be able to build postgres (7.4.3) with a given --prefix, but then pack up the installation directory and deploy it in another directory (as part of a product install, for instance). I configured with --disable-rpath, but I'm still getting the creating conversions... ERROR: could not access file "$libdir/ascii_and_mic": No such file or directory error when I try to run initdb from the new location. This is on Solaris 9, and I've verified that my LD_LIBRARY_PATH includes the postgres/lib dir in the new location. Is there a way I can get around this at runtime? I was under the impression that --disable-rpath prevented library paths from being compiled into the code, but maybe this "$libdir" is a different thing? Thanks in advance for any help. - DAP ====================================================== David Parker Tazz Networks (401) 709-5130 ---------------------------(end of broadcast)--------------------------- TIP 7: don't forget to increase your free space map settings
David Parker wrote: > I need to be able to build postgres (7.4.3) with a given --prefix, > but then pack up the installation directory and deploy it in another > directory (as part of a product install, for instance). > > I configured with --disable-rpath, but I'm still getting the This doesn't work. There are a lot more paths compiled in than just the rpath. If you want to change the installation paths, you need to rebuild from scratch. -- Peter Eisentraut http://developer.postgresql.org/~petere/
Either a) modify share/conversion_create.sql to specify a full path or b) modify share/conversion_create.sql to simply remove "$libdir/" everywhere, then setting dynamic_library_path in share/postgresql.conf.sample allows initdb and createdb to run, which was my initial stumbling block. I haven't done anything in particular with the resulting database yet. Do you expect the installation to break in other places? It would be nice if that $libdir just weren't in the conversion_create.sql at all: it only represents the compiled-in default, which the program knows anyway, and having it there prevents the dynamic_library_path setting from having any effect - at least that's what seems to be happening. I don't what other effects that variable might be having, of course. Thanks. - DAP -----Original Message----- From: Peter Eisentraut [mailto:peter_e@gmx.net] Sent: Thursday, July 15, 2004 5:33 PM To: David Parker; pgsql-general@postgresql.org Subject: Re: [GENERAL] moving an installation David Parker wrote: > I need to be able to build postgres (7.4.3) with a given --prefix, but > then pack up the installation directory and deploy it in another > directory (as part of a product install, for instance). > > I configured with --disable-rpath, but I'm still getting the This doesn't work. There are a lot more paths compiled in than just the rpath. If you want to change the installation paths, you need to rebuild from scratch. -- Peter Eisentraut http://developer.postgresql.org/~petere/
Peter Eisentraut <peter_e@gmx.net> writes:
> David Parker wrote:
>> I need to be able to build postgres (7.4.3) with a given --prefix,
>> but then pack up the installation directory and deploy it in another
>> directory (as part of a product install, for instance).
> This doesn't work.
Not at the moment anyway. Bruce and some other people did some work
last month towards supporting relocatable installs --- David, would you
like to experiment with CVS tip and see if it works for you?
regards, tom lane
David Parker wrote: > allows initdb and createdb to run, which was my initial stumbling > block. I haven't done anything in particular with the resulting > database yet. Do you expect the installation to break in other > places? Off the top of my head, at least createlang, pg_dumpall, and ecpg will have problems. -- Peter Eisentraut http://developer.postgresql.org/~petere/
Oh, that's good to know. I haven't ventured into what's going on in CVS
yet, so this will be a good excuse.
Thanks.
- DAP
-----Original Message-----
From: pgsql-general-owner@postgresql.org
[mailto:pgsql-general-owner@postgresql.org] On Behalf Of Tom Lane
Sent: Thursday, July 15, 2004 10:31 PM
To: Peter Eisentraut
Cc: David Parker; pgsql-general@postgresql.org
Subject: Re: [GENERAL] moving an installation
Peter Eisentraut <peter_e@gmx.net> writes:
> David Parker wrote:
>> I need to be able to build postgres (7.4.3) with a given --prefix,
>> but then pack up the installation directory and deploy it in another
>> directory (as part of a product install, for instance).
> This doesn't work.
Not at the moment anyway. Bruce and some other people did some work
last month towards supporting relocatable installs --- David, would you
like to experiment with CVS tip and see if it works for you?
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings
David Parker wrote: > Oh, that's good to know. I haven't ventured into what's going on in CVS > yet, so this will be a good excuse. > Or you can download a recent snapshot of CVS from our ftp servers. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
I built tip, and the moveable installation does indeed appear to work: I
did an initdb,createlang, and then paddled around with psql a bit, but
nothing more serious than that yet.
Is the current tip destined for a 7.4.x, or has 7.4.x been branched?
Will it be in 7.5?
Thanks for the tip tip ;-)
- DAP
-----Original Message-----
From: pgsql-general-owner@postgresql.org
[mailto:pgsql-general-owner@postgresql.org] On Behalf Of Tom Lane
Sent: Thursday, July 15, 2004 10:31 PM
To: Peter Eisentraut
Cc: David Parker; pgsql-general@postgresql.org
Subject: Re: [GENERAL] moving an installation
Peter Eisentraut <peter_e@gmx.net> writes:
> David Parker wrote:
>> I need to be able to build postgres (7.4.3) with a given --prefix,
>> but then pack up the installation directory and deploy it in another
>> directory (as part of a product install, for instance).
> This doesn't work.
Not at the moment anyway. Bruce and some other people did some work
last month towards supporting relocatable installs --- David, would you
like to experiment with CVS tip and see if it works for you?
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings
David Parker wrote: > I built tip, and the moveable installation does indeed appear to work: I > did an initdb,createlang, and then paddled around with psql a bit, but > nothing more serious than that yet. > > Is the current tip destined for a 7.4.x, or has 7.4.x been branched? > Will it be in 7.5? > > Thanks for the tip tip ;-) The tip is headed for 7.5. It will not appear in 7.4.X. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
Hello Everybody,
I am going to load postgresql 7.4 in
Irix 6.5.20, MIPS processor
Please help me out with gcc/cc idea
As far as I understood, I have to use gmake (as I have
done in all other OS) and native cc in place of gcc.
As par the installation guide the command should be
something like
./configure CC={cc compiler path} CFLAGS='-O2 -pipe'
But I cant understand the what does the CFLAG
parameter mean. Could u please throw some light on
that at least it would be helpful if u specify the
exact configure command line u have used for Irix
6.5.20 native c compiler.
Thank you,
Regards
Nil Banerjee
ALL-NEW Yahoo! Messenger - sooooo many all-new ways to express yourself http://uk.messenger.yahoo.com
Nilabhra Banerjee wrote:
> As par the installation guide the command should be
> something like
> ./configure CC={cc compiler path} CFLAGS='-O2 -pipe'
>
> But I cant understand the what does the CFLAG
> parameter mean. Could u please throw some light on
> that
The installation instructions say that you *can* override the default
compiler flags with the CFLAGS variable, not that you have to.
> at least it would be helpful if u specify the
> exact configure command line u have used for Irix
> 6.5.20 native c compiler.
./configure CC=cc
make
make install
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
Thanks a lot.. This much is enough for me....If I get
some time afterwards I go thru it again.... But I am
still curious to know about the CFlags variable..what
are the other values it can take.
A big THANKS
Nil Banerjee
--- Peter Eisentraut <peter_e@gmx.net> wrote: >
Nilabhra Banerjee wrote:
> > As par the installation guide the command should
> be
> > something like
> > ./configure CC={cc compiler path} CFLAGS='-O2
> -pipe'
> >
> > But I cant understand the what does the CFLAG
> > parameter mean. Could u please throw some light on
> > that
>
> The installation instructions say that you *can*
> override the default
> compiler flags with the CFLAGS variable, not that
> you have to.
>
> > at least it would be helpful if u specify the
> > exact configure command line u have used for Irix
> > 6.5.20 native c compiler.
>
> ./configure CC=cc
> make
> make install
>
> --
> Peter Eisentraut
> http://developer.postgresql.org/~petere/
>
>
___________________________________________________________ALL-NEW Yahoo! Messenger - sooooo many all-new ways to
expressyourself http://uk.messenger.yahoo.com
Nilabhra Banerjee wrote: > Thanks a lot.. This much is enough for me....If I get > some time afterwards I go thru it again.... But I am > still curious to know about the CFlags variable..what > are the other values it can take. Depends on your system. Try "man cc". -- Peter Eisentraut http://developer.postgresql.org/~petere/
=?iso-8859-1?q?Nilabhra=20Banerjee?= <nil_ban@yahoo.co.uk> wrote: > > > Thanks a lot.. This much is enough for me....If I get > some time afterwards I go thru it again.... But I am > still curious to know about the CFlags variable..what > are the other values it can take. The pgsql tarball includes an INSTALL document. The INSTALL file, in turn, explains what the CFLAGS variable does. What's assigned to CFLAGS is dependent on a number of factors, such as operating system and version, compiler and version, hardware, etc., etc. Jim
Dear Nil,
Yes, the important thing is to use the MIPS compilers, not
gcc. You have your choice of compiler environments -- I suggest using
the 64-bit compilation model (CC="cc -64") -- you can use much bigger
buffer caches that way if you have sufficient RAM. --Bob
>
> Hello Everybody,
>
> I am going to load postgresql 7.4 in
> Irix 6.5.20, MIPS processor
>
> Please help me out with gcc/cc idea
>
> As far as I understood, I have to use gmake (as I have
> done in all other OS) and native cc in place of gcc.
>
> As par the installation guide the command should be
> something like
> ./configure CC={cc compiler path} CFLAGS='-O2 -pipe'
>
> But I cant understand the what does the CFLAG
> parameter mean. Could u please throw some light on
> that at least it would be helpful if u specify the
> exact configure command line u have used for Irix
> 6.5.20 native c compiler.
>
> Thank you,
>
> Regards
> Nil Banerjee
>
>
>
>
>
> ALL-NEW Yahoo! Messenger - sooooo many all-new ways to express yourself http://uk.messenger.yahoo.com
>
+-----------------------------+------------------------------------+
| Robert E. Bruccoleri, Ph.D. | email: bruc@acm.org |
| President, Congenair LLC | URL: http://www.congen.com/~bruc |
| P.O. Box 314 | Phone: 609 818 7251 |
| Pennington, NJ 08534 | |
+-----------------------------+------------------------------------+
Hi,
i am needing an aggregate-function wich calculates an weighted average about some rows.
for this reason i was creating a new complex type called 'wnumeric' and worked out all the
service-functions for the aggregate. everything is working fine, except that the first row will not
passed through the state-function (weighted_accum). instead the values of the first row are used
directly as init-state.
Now i tried to set the init-state to wnumeric(0, 0), but it wont work. The INITCOND-paramter only
accept string-literals like '0, 0', '(0.0,0.0)', but if i use the agrregate i get always this:
'ERROR: Cannot accept a constant of type RECORD'.
I think postgresql cast the INITCOND to the Type RECORD, what is wrong.
Can anyone help me to solve this problem?
Here comes the code:
CREATE TYPE "public"."wnumeric" AS (
"weight" REAL,
"value" NUMERIC
);
CREATE OR REPLACE FUNCTION "public"."wnumeric" (real, numeric) RETURNS "public"."wnumeric" AS'
DECLARE
_WEIGHT ALIAS FOR $1;
_VALUE ALIAS FOR $2;
_OUT "wnumeric"%rowtype;
BEGIN
SELECT INTO _OUT _WEIGHT, _VALUE;
RETURN _OUT;
END;
'LANGUAGE 'plpgsql' VOLATILE RETURNS NULL ON NULL INPUT SECURITY INVOKER;
CREATE OR REPLACE FUNCTION "public"."weighted_accum" ("public"."wnumeric", "public"."wnumeric")
RETURNS "public"."wnumeric" AS'
DECLARE
_STATE ALIAS FOR $1;
_IN ALIAS FOR $2;
_OUT wnumeric%rowtype;
BEGIN
IF _IN.weight > 0 THEN
_OUT.weight = _STATE.weight + _IN.weight;
_OUT.value = _STATE.value * _STATE.weight + _IN.value;
ELSE
_OUT.weight = _STATE.weight;
_OUT.value = _STATE.value;
END IF;
RETURN _OUT;
END
'LANGUAGE 'plpgsql' VOLATILE RETURNS NULL ON NULL INPUT SECURITY INVOKER;
CREATE OR REPLACE FUNCTION "public"."weighted_avg" ("public"."wnumeric") RETURNS numeric AS'
DECLARE
_STATE ALIAS FOR $1;
_OUT numeric;
BEGIN
IF _STATE.weight > 0 THEN
_OUT = _STATE.value / _STATE.weight;
ELSE
_OUT = _STATE.value;
END IF;
RETURN _OUT;
END
'LANGUAGE 'plpgsql' VOLATILE RETURNS NULL ON NULL INPUT SECURITY INVOKER;
CREATE AGGREGATE wavg(
BASETYPE=wnumeric,
SFUNC=weighted_accum,
STYPE=wnumeric,
FINALFUNC=weighted_avg
);
this produces the error:
CREATE AGGREGATE wavg(
BASETYPE=wnumeric,
SFUNC=weighted_accum,
STYPE=wnumeric,
FINALFUNC=weighted_avg
INITCOND='(1.0,1.0)'
);
regards
thomas!
"Thomas Chille" <thomas@chille.de> writes:
> Now i tried to set the init-state to wnumeric(0, 0), but it wont work. The INITCOND-paramter only
> accept string-literals like '0, 0', '(0.0,0.0)', but if i use the agrregate i get always this:
> 'ERROR: Cannot accept a constant of type RECORD'.
This isn't going to work in existing releases, but FWIW it does work in 8.0.
Do you really need the weight and the value to be of different
datatypes? You could make it work in current releases by using
a two-element array as the state type.
BTW, as far as I can see all those functions would be better defined
as IMMUTABLE than VOLATILE.
regards, tom lane