Thread: createdb script bug in 7.3RC2?
Seems to be a bug in the bin/createdb script. I tried to use the script as is and got the following error: $ createlang plpgsql JC ERROR: stat failed on file '$libdir/plpgsql': No such file or directory createlang: language installation failed But my PGLIB path is correct: $ set | grep PG PGDATA=/usr/local/pgsql/data PGLIB=/usr/local/pgsql/lib I editing bin/createdb, hard coding the value of PGLIB and createdb then worked fine. The edits are given below.I don't know any shell scripting or much about pg's internal so I have no idea why this problem occurs. But I can see why createdb can't figure out by itself what the value of PGLIB is. The edits on bin/createlang: 189a190 > PGLIB=/usr/local/pgsql/lib Hope this helps. And if it is not a bug but a problem with my installation, configuration please let me know. Jc
Jean-Christian Imbeault <jc@mega-bucks.co.jp> writes:
> I editing bin/createdb, hard coding the value of PGLIB and createdb then
> worked fine.
This is certainly not the correct solution.
regards, tom lane
Tom Lane wrote: > >>I editing bin/createdb, hard coding the value of PGLIB and createdb then >>worked fine. > > This is certainly not the correct solution. I certainly agree. What can I do to pin-point the root cause of the problem? My environment vars seem to be set correctly so I don't understand why the createlang script is not picking them up ... Jc
Jean-Christian Imbeault <jc@mega-bucks.co.jp> writes:
>> This is certainly not the correct solution.
> I certainly agree. What can I do to pin-point the root cause of the
> problem? My environment vars seem to be set correctly so I don't
> understand why the createlang script is not picking them up ...
I'm still wondering if you are actually invoking a 7.3 server, and not
an old pre-7.1 one. 'psql -c "select version()"' would tell the tale.
Barring that, try adding some debug printouts to
expand_dynamic_library_name() in src/backend/utils/fmgr/dfmgr.c
to see what file names it's actually trying (or just step through it
with a debugger).
regards, tom lane
Tom Lane wrote:
>
> I'm still wondering if you are actually invoking a 7.3 server, and not
> an old pre-7.1 one. 'psql -c "select version()"' would tell the tale.
[postgres@localhost work]$ psql JC -c "select version()"
version
--------------------------------------------------------------
PostgreSQL 7.3rc2 on i686-pc-linux-gnu, compiled by GCC 2.96
(1 row)
> Barring that, try adding some debug printouts to
> expand_dynamic_library_name() in src/backend/utils/fmgr/dfmgr.c
> to see what file names it's actually trying (or just step through it
> with a debugger).
I'll try but that's a bit over my head ... I don't know much C or shell
programming.
Jc
As a follow-up I get an error when dropping plpgsql and then trying to re-create it ... $ psql JC -c "drop language plpgsql cascade" NOTICE: Drop cascades to function cancell_all_li() NOTICE: Drop cascades to trigger insert_invoices on table invoices NOTICE: Drop cascades to function update_invoice_price() NOTICE: Drop cascades to trigger update_invoice_li_price on table invoice_li NOTICE: Drop cascades to function max(date,date,date) DROP LANGUAGE $ createlang plpgsql JC ERROR: function plpgsql_call_handler already exists with same argument types createlang: language installation failed Once a language is dropped I should be able to re-add it no? Or isn't dropping it enough? Jc
You must have been right about the problem being due to something being leftover from the old DB because I cannot recreate the problem anymore. Sorry to have spotted a non-existent bug. Jc
Jean-Christian Imbeault <jc@mega-bucks.co.jp> writes:
> As a follow-up I get an error when dropping plpgsql and then trying to
> re-create it ...
> $ psql JC -c "drop language plpgsql cascade"
> NOTICE: Drop cascades to function cancell_all_li()
> NOTICE: Drop cascades to trigger insert_invoices on table invoices
> NOTICE: Drop cascades to function update_invoice_price()
> NOTICE: Drop cascades to trigger update_invoice_li_price on table
> invoice_li
> NOTICE: Drop cascades to function max(date,date,date)
> DROP LANGUAGE
> $ createlang plpgsql JC
> ERROR: function plpgsql_call_handler already exists with same argument
> types
> createlang: language installation failed
> Once a language is dropped I should be able to re-add it no? Or isn't
> dropping it enough?
DROP LANGUAGE only drops the pg_language entry, not the call handler.
I think the dropdb script would drop the handler too, but you didn't
do that.
regards, tom lane
I said:
> DROP LANGUAGE only drops the pg_language entry, not the call handler.
> I think the dropdb script would drop the handler too, but you didn't
> do that.
s/dropdb/droplang/, of course. Sorry.
regards, tom lane
Jean-Christian Imbeault writes: > But my PGLIB path is correct: PGLIB doesn't do anything. At all. Really. -- Peter Eisentraut peter_e@gmx.net