Обсуждение: Problem in current CVS
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
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, Pennsylvania19026
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
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
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
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
>
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
>
"Mitch Vincent" <mitch@venux.net> writes:
> This might sound like an ignorant question but how does one dump the
> function catalog?
Tryselect * 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
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
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 >
"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
[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) #
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 >
"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