Just downloaded a completely fresh cvs copy. When I
do initdb...

This user will own all the files and must also own the server process.

Creating Postgres database system directory /home/pghack/pgsql/data

Creating Postgres database system directory /home/pghack/pgsql/data/base

Creating template database in /home/pghack/pgsql/data/base/template1
ERROR:  Error: unknown type 'oidvector'.

ERROR:  Error: unknown type 'oidvector'.

        syntax error 12 : parse errorinitdb: could not create template
database

Tue, 01 Feb 2000 23:14:33 +1100
Chris <chris@bitmead.com>
Problem in current CVS
Did you do a 'make clean'?

> Just downloaded a completely fresh cvs copy. When I
> do initdb...
> 
> This user will own all the files and must also own the server process.
> 
> Creating Postgres database system directory /home/pghack/pgsql/data
> 
> Creating Postgres database system directory /home/pghack/pgsql/data/base
> 
> Creating template database in /home/pghack/pgsql/data/base/template1
> ERROR:  Error: unknown type 'oidvector'.
> 
> ERROR:  Error: unknown type 'oidvector'.
> 
>         syntax error 12 : parse errorinitdb: could not create template
> database
> 
> ************
> 


-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  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

Tue, 1 Feb 2000 08:47:43 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: [HACKERS] Problem in current CVS
Bruce Momjian wrote:
> 
> Did you do a 'make clean'?

Oops, my different installations are getting mixed up. My fault.


> 
> > Just downloaded a completely fresh cvs copy. When I
> > do initdb...
> >
> > This user will own all the files and must also own the server process.
> >
> > Creating Postgres database system directory /home/pghack/pgsql/data
> >
> > Creating Postgres database system directory /home/pghack/pgsql/data/base
> >
> > Creating template database in /home/pghack/pgsql/data/base/template1
> > ERROR:  Error: unknown type 'oidvector'.
> >
> > ERROR:  Error: unknown type 'oidvector'.
> >
> >         syntax error 12 : parse errorinitdb: could not create template
> > database
> >
> > ************
> >
> 
> --
>   Bruce Momjian                        |  http://www.op.net/~candle
>   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

-- 
Chris Bitmead
mailto:chris@bitmead.com
http://www.techphoto.org - Photography News, Stuff that Matters

Wed, 02 Feb 2000 01:06:50 +1100
Chris <chris@bitmead.com>
Re: [HACKERS] Problem in current CVS
The strangest thing started happening on one of my boxes today running
Postgre.

I'm using a function to total up values in a table.. The exact same code is
on our development and live server yet on the live server I get :


ERROR:  stat failed on file '${exec_prefix}/lib/plpgsql.so': No such file or
directory


Anytime the function is called.

The plpgsql.so library is in the exact same place on both machine with the
exact same permissions.

I can't find any reference to the $exec_prefix variable on either machine,
yet it works on the development server and not on the live server.

Thanks for *any* hints, help or ideas.

-Mitch



Tue, 1 Feb 2000 10:07:59 -0500
"Mitch Vincent" <mitch@venux.net>
plpgsql problem..
Mitch Vincent wrote:

> ERROR:  stat failed on file '${exec_prefix}/lib/plpgsql.so': No such file or
> directory

> I can't find any reference to the $exec_prefix variable on either machine,
> yet it works on the development server and not on the live server.

PostgreSQL does not expand environment variables when looking for
function code. Presumably your installer is broken and did not
substitute the variable at install time on the affected system. You
might dump your function catalog on both systems to compare - if the
function path on the sane system contains a variable as well, there is
some strange magic going on there.

Sevo

Tue, 01 Feb 2000 16:28:33 +0100
Sevo Stille <sevo@ip23.net>
Re: [HACKERS] plpgsql problem..
This might sound like an ignorant question but how does one dump the
function catalog?

----- Original Message -----
From: Sevo Stille <sevo@ip23.net>
To: Mitch Vincent <mitch@venux.net>
Cc: Postgres Hackers List <hackers@postgreSQL.org>
Sent: Tuesday, February 01, 2000 10:28 AM
Subject: Re: [HACKERS] plpgsql problem..


> Mitch Vincent wrote:
>
> > ERROR:  stat failed on file '${exec_prefix}/lib/plpgsql.so': No such
file or
> > directory
>
> > I can't find any reference to the $exec_prefix variable on either
machine,
> > yet it works on the development server and not on the live server.
>
> PostgreSQL does not expand environment variables when looking for
> function code. Presumably your installer is broken and did not
> substitute the variable at install time on the affected system. You
> might dump your function catalog on both systems to compare - if the
> function path on the sane system contains a variable as well, there is
> some strange magic going on there.
>
> Sevo
>


Tue, 1 Feb 2000 10:31:08 -0500
"Mitch Vincent" <mitch@venux.net>
Re: [HACKERS] plpgsql problem..
Just an additional comment.

I re-configured and re-installed Postgre and there is no change...

I'm baffled....

----- Original Message -----
From: Sevo Stille <sevo@ip23.net>
To: Mitch Vincent <mitch@venux.net>
Cc: Postgres Hackers List <hackers@postgreSQL.org>
Sent: Tuesday, February 01, 2000 10:28 AM
Subject: Re: [HACKERS] plpgsql problem..


> Mitch Vincent wrote:
>
> > ERROR:  stat failed on file '${exec_prefix}/lib/plpgsql.so': No such
file or
> > directory
>
> > I can't find any reference to the $exec_prefix variable on either
machine,
> > yet it works on the development server and not on the live server.
>
> PostgreSQL does not expand environment variables when looking for
> function code. Presumably your installer is broken and did not
> substitute the variable at install time on the affected system. You
> might dump your function catalog on both systems to compare - if the
> function path on the sane system contains a variable as well, there is
> some strange magic going on there.
>
> Sevo
>


Tue, 1 Feb 2000 10:58:50 -0500
"Mitch Vincent" <mitch@venux.net>
Re: [HACKERS] plpgsql problem..
"Mitch Vincent" <mitch@venux.net> writes:
> This might sound like an ignorant question but how does one dump the
> function catalog?

Try
	select * from pg_proc where proname = 'functionOfInterest';

I think Sevo has identified the problem though: the CREATE FUNCTION
command for the plpgsql_call_handler function needs to give an exact
path name.  What you are showing looks like the command tried to use an
environment variable and the substitution didn't happen.  Better review
the procedure you used to install plpgsql.  I'd recommend using the
createlang script, btw, not doing it by hand.

			regards, tom lane

Tue, 01 Feb 2000 11:08:55 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] plpgsql problem.. 
Mitch Vincent wrote:
> 
> This might sound like an ignorant question but how does one dump the
> function catalog?

The functions are in pg_proc. So generally, it would be "select * from
pg_proc". For the given problem, "select proname,probin from pg_proc;"
would be sufficient. Dump to a importable set of SQL statements, as in
pg_dump, can't be done - restoring a system table would hose the id
references, so exporting to a restorable format is of no use.

Sevo

Tue, 01 Feb 2000 17:21:12 +0100
Sevo Stille <sevo@ip23.net>
Re: [HACKERS] plpgsql problem..
I used mklang.sql in the plpgsql directory to install the language.. It's
the same thing I used on the working devel server..

--
-- PL/pgSQL language declaration
--
-- $Header: /usr/local/cvsroot/pgsql/src/pl/plpgsql/src/mklang.sql.in,v 1.4
1999/05/11 22:57:50 tgl Exp $
--

create function plpgsql_call_handler() returns opaque
        as '/usr/local/pgsql/plpgsql.so'
        lib/language 'C';

create trusted procedural language 'plpgsql'
        handler plpgsql_call_handler
        lancompiler 'PL/pgSQL';

That's the contents of that file and /usr/local/pgsql/plpgsql.so is exactly
where plpgsql.so is.




----- Original Message -----
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Mitch Vincent <mitch@venux.net>
Cc: <hackers@postgreSQL.org>; <sevo@ip23.net>
Sent: Tuesday, February 01, 2000 11:08 AM
Subject: Re: [HACKERS] plpgsql problem..


> "Mitch Vincent" <mitch@venux.net> writes:
> > This might sound like an ignorant question but how does one dump the
> > function catalog?
>
> Try
> select * from pg_proc where proname = 'functionOfInterest';
>
> I think Sevo has identified the problem though: the CREATE FUNCTION
> command for the plpgsql_call_handler function needs to give an exact
> path name.  What you are showing looks like the command tried to use an
> environment variable and the substitution didn't happen.  Better review
> the procedure you used to install plpgsql.  I'd recommend using the
> createlang script, btw, not doing it by hand.
>
> regards, tom lane
>


Tue, 1 Feb 2000 11:29:54 -0500
"Mitch Vincent" <mitch@venux.net>
Re: [HACKERS] plpgsql problem.. 
"Mitch Vincent" <mitch@venux.net> writes:
> I used mklang.sql in the plpgsql directory to install the language.. It's
> the same thing I used on the working devel server..

Odd.  So what is in pg_proc for plpgsql_call_handler?

			regards, tom lane

Tue, 01 Feb 2000 11:38:02 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] plpgsql problem.. 
[Charset iso-8859-1 unsupported, filtering to ASCII...]
> Just an additional comment.
>
> I re-configured and re-installed Postgre and there is no change...
>
> I'm baffled....

    Which  version  of  PostgreSQL  and  how  do  you install the
    PL/pgSQL language in the database?

    In either case, the support  script  you're  using  issues  a
    damaged  CREATE  FUNCTION command for the PL handler. Somehow
    the  build/install  did  not  replace  it  with  the   actual
    installation path.

    After that, initdb again and anything should be fine.


Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#========================================= wieck@debis.com (Jan Wieck) #



Tue, 1 Feb 2000 17:51:01 +0100 (CET)
wieck@debis.com (Jan Wieck)
Re: [HACKERS] plpgsql problem..
Ok guys, brand new problem!

Now the backend segfaults.




query: begin transaction
ProcessUtility: begin transaction
CommitTransactionCommand
StartTransactionCommand
query: insert into
agencys(agency_id,created,createdby,updated,updatedby,loginallow,memberdate,
agencycode,agencyowner,agencyname,address1,address2,city,state,postal,countr
y,fed_taxid,naps_member,email,url,fee_sched,refund_policy,membership_type,up
s_type,invoice_hard_copy,zerodate,balance) values
(487,'now',291,'now',291,0,'02-01-2000','TEST-123','Mitch Vincent','Test
INC','knkln','lknlkn','lknlkn','ky','41101','US','','f','mitch@lala.com','ww
w.mitch.com','','jnblj','trac','f','f','12-01-1999',0)
ProcessQuery
CommitTransactionCommand
StartTransactionCommand
query: update agencys set specialization='dfdf' where agency_id=487
ProcessQuery
CommitTransactionCommand
StartTransactionCommand
query: update agencys set background='fdf' where agency_id=487
ProcessQuery
CommitTransactionCommand
StartTransactionCommand
query: delete from agencys_phones where agency_id=487
ProcessQuery
CommitTransactionCommand
StartTransactionCommand
query: insert into agencys_logins (agency_id,month,maxallowed) values
(487,'02-01-2000',0)
ProcessQuery
CommitTransactionCommand
StartTransactionCommand
query: insert into accounting(agency_id,month,totaljobs,totalapps) values
(487,'02-01-2000',0,0)
ProcessQuery
CommitTransactionCommand
StartTransactionCommand
query: insert into invoice
(invoice_number,agencycode,invoice_date,fee_membership,fee_logins,fee_conven
tion,fee_prints_jobs,fee_prints_apps,fee_hotlines,fee_postage,fee_ups,fee_la
te,fee_other1,other_desc1,fee_other2,other_desc2,fee_other3,other_desc3,fee_
pastdue,amount_paid,paid,total)
values(1,'TEST-123','02-01-2000',193.33333333333,0,0,0,0,0,0,0,0,0,'',0,'',0
,'',0,0,'f',0)
ProcessQuery
query: SELECT $1 + $2 + $3 + $4 + $5 + $6 + $7 + $8 + $9 + $10 + $11 + $12 +
$13 - $14
CommitTransactionCommand
StartTransactionCommand
query: select * from invoice where invoice_number=1
ProcessQuery
CommitTransactionCommand
pq_recvbuf: unexpected EOF on client connection
proc_exit(0) [#0]
shmem_exit(0) [#0]
exit(0)
/usr/local/pgsql/bin/postmaster: reaping dead processes...
/usr/local/pgsql/bin/postmaster: CleanupProc: pid 75928 exited with status 0


I get that in the log file.... Can anyone see anything that might point to
the reason behind the segfault?


You guys have no idea how much I appreciate your help.. Thanks one and all.

-Mitch




----- Original Message -----
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Mitch Vincent <mitch@venux.net>
Sent: Tuesday, February 01, 2000 11:49 AM
Subject: Re: [HACKERS] plpgsql problem..


> "Mitch Vincent" <mitch@venux.net> writes:
> > plpgsql_call_handler|    1002|     13|f       |t           |f
|
> > 0|f        |         0|0 0 0 0 0 0 0 0|        100|             0|
> > 0|           100|-     |/usr/local/pgsql/lib/plpgsql.so
> > (1 row)
>
> That looks like it should work now...
>
> > Hmm, get this, now I have another error after droping and re-creating
the
> > language and function.
>
> > ERROR: fmgr_info: Cache lookup for language failed 4427969
>
> It sounds like your language entry is still pointing at the old
> function.  (There's no interlock to keep you from dropping a function
> that things still depend on ... probably there should be ...)
>
> Try recreating the language entry now that you've remade the function.
>
> regards, tom lane
>


Tue, 1 Feb 2000 12:49:45 -0500
"Mitch Vincent" <mitch@venux.net>
Re: [HACKERS] plpgsql problem.. 
"Mitch Vincent" <mitch@venux.net> writes:
> Ok guys, brand new problem!
> Now the backend segfaults.

> StartTransactionCommand
> query: select * from invoice where invoice_number=1
> ProcessQuery
> CommitTransactionCommand
> pq_recvbuf: unexpected EOF on client connection
> proc_exit(0) [#0]
> shmem_exit(0) [#0]
> exit(0)
> /usr/local/pgsql/bin/postmaster: reaping dead processes...
> /usr/local/pgsql/bin/postmaster: CleanupProc: pid 75928 exited with status 0

> I get that in the log file.... Can anyone see anything that might point to
> the reason behind the segfault?

Um, I see no backend segfault there --- I see a backend exiting in a
perfectly orderly fashion after detecting that the client closed the
channel.  The client didn't send the expected "quit" (X) message,
which might or might not be normal behavior for that client.  But if
you've got a backend segfault problem, this doesn't document it...

			regards, tom lane

Tue, 01 Feb 2000 23:09:37 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] plpgsql problem.. 