Обсуждение: plpgsql & bsdi 4.0
Hi folks,
I'm trying to bring up postgresql 6.5.2 on a BSDI 4.0
box, and I'd like a little help -- if only a "please go to this list and
bug them about it" note.
The only hang-up seems to be that plpgsql doesn't work out of
the box, and can't be easily cajoled into doing so.
When I did a
gmake clean
gmake distclean
./configure --prefix=/usr/local/pgsql.new --with-template=bsdi_4.0 --with-pgport=4532
gmake
and ran regression, plpgsql failed -- lots of these errors should
up in the output of postmaster:
/usr/local/pgsql.new/bin/postmaster: can't resolve symbol 'plpgsql_yylineno'
ERROR: Load of file /usr/local/pgsql.new/lib/plpgsql.so failed: Unable to resolve symbol
(I should mention that all of these outputs are cut-and-paste from vi's of the log
files, so control characters are "nicer" than they actually are in those files.)
So I changed one line in scan.l to make sure plpgsql_yylineno was resolved, and
now it *mostly* works.
The new problem is that plpgsql is still giving an error:
Again, here's the relevant portion of the postmaster output:
...
ERROR: Relation 'tmp' does not have attribute 'k'
NOTICE: plpgsql: ERROR during compile of wslot_slotlink_view near line 1
ERROR: syntax error at or near "q0xf2&^H^F"
DEBUG: Last error occured while executing PL/pgSQL function pslot_backlink_view
DEBUG: line 1 at return
NOTICE: plpgsql: ERROR during compile of wslot_slotlink_view near line 1
ERROR: syntax error at or near "q0xf2&^H^F"
DEBUG: Last error occured while executing PL/pgSQL function pslot_backlink_view
DEBUG: line 1 at return
ERROR: Cannot insert a duplicate key into a unique index
ERROR: WS.not.there does not exists
ERROR: illegal backlink beginning with XX
ERROR: PS.not.there does not exists
ERROR: illegal slotlink beginning with XX
ERROR: Cannot insert a duplicate key into a unique index
ERROR: no manual manipulation of HSlot
ERROR: no manual manipulation of HSlot
ERROR: system "notthere" does not exist
ERROR: IFace slotname "IF.orion.ethernet_interface_name_too_long" too long (20 char max)
ERROR: temptest: Table does not exist.
DEBUG: --Relation num_exp_add--
DEBUG: Pages 2: Changed 0, Reapped 0, Empty 0, New 0; Tup 100: Vac 0, Keep/VTL 0/0, Crash 0, UnUsed 0, MinLen 50,
MaxLen118; R
...
Below is the corresponding diff from the regression.diffs file.
*** expected/plpgsql.out Wed Sep 30 23:38:35 1998
--- results/plpgsql.out Sun Sep 19 01:48:14 1999
***************
*** 1275,1319 ****
QUERY: insert into IFace values ('IF', 'orion', 'eth0', 'WS.002.1b');
QUERY: update PSlot set slotlink = 'HS.base.hub1.1' where slotname = 'PS.base.b2';
QUERY: select * from PField_v1 where pfname = 'PF0_1' order by slotname;
! pfname|slotname |backside |patch
!
------+--------------------+--------------------------------------------------------+---------------------------------------------
! PF0_1 |PS.base.a1 |WS.001.1a in room 001 -> Phone PH.hc001 (Hicom standard)|PS.base.ta1 -> Phone line -0
(Centralcall)
! PF0_1 |PS.base.a2 |WS.001.1b in room 001 -> - |-
! PF0_1 |PS.base.a3 |WS.001.2a in room 001 -> Phone PH.fax001 (Canon fax) |PS.base.ta2 -> Phone line -501
(Faxentrance)
! PF0_1 |PS.base.a4 |WS.001.2b in room 001 -> - |-
! PF0_1 |PS.base.a5 |WS.001.3a in room 001 -> - |-
! PF0_1 |PS.base.a6 |WS.001.3b in room 001 -> - |-
! PF0_1 |PS.base.b1 |WS.002.1a in room 002 -> Phone PH.hc002 (Hicom standard)|PS.base.ta5 -> Phone line -103
! PF0_1 |PS.base.b2 |WS.002.1b in room 002 -> orion IF eth0 (PC) |Patchfield PF0_1 hub slot 1
! PF0_1 |PS.base.b3 |WS.002.2a in room 002 -> Phone PH.hc003 (Hicom standard)|PS.base.tb2 -> Phone line -106
! PF0_1 |PS.base.b4 |WS.002.2b in room 002 -> - |-
! PF0_1 |PS.base.b5 |WS.002.3a in room 002 -> - |-
! PF0_1 |PS.base.b6 |WS.002.3b in room 002 -> - |-
! PF0_1 |PS.base.c1 |WS.003.1a in room 003 -> - |-
! PF0_1 |PS.base.c2 |WS.003.1b in room 003 -> - |-
! PF0_1 |PS.base.c3 |WS.003.2a in room 003 -> - |-
! PF0_1 |PS.base.c4 |WS.003.2b in room 003 -> - |-
! PF0_1 |PS.base.c5 |WS.003.3a in room 003 -> - |-
! PF0_1 |PS.base.c6 |WS.003.3b in room 003 -> - |-
! (18 rows)
!
QUERY: select * from PField_v1 where pfname = 'PF0_2' order by slotname;
! pfname|slotname |backside |patch
!
------+--------------------+------------------------------+----------------------------------------------------------------------
! PF0_2 |PS.base.ta1 |Phone line -0 (Central call) |PS.base.a1 -> WS.001.1a in room 001 -> Phone PH.hc001
(Hicomstandard)
! PF0_2 |PS.base.ta2 |Phone line -501 (Fax entrance)|PS.base.a3 -> WS.001.2a in room 001 -> Phone PH.fax001
(Canonfax)
! PF0_2 |PS.base.ta3 |Phone line -102 |-
! PF0_2 |PS.base.ta4 |- |-
! PF0_2 |PS.base.ta5 |Phone line -103 |PS.base.b1 -> WS.002.1a in room 002 -> Phone PH.hc002
(Hicomstandard)
! PF0_2 |PS.base.ta6 |Phone line -104 |-
! PF0_2 |PS.base.tb1 |- |-
! PF0_2 |PS.base.tb2 |Phone line -106 |PS.base.b3 -> WS.002.2a in room 002 -> Phone PH.hc003
(Hicomstandard)
! PF0_2 |PS.base.tb3 |Phone line -108 |-
! PF0_2 |PS.base.tb4 |Phone line -109 |-
! PF0_2 |PS.base.tb5 |Phone line -121 |-
! PF0_2 |PS.base.tb6 |Phone line -122 |-
! (12 rows)
!
QUERY: insert into PField values ('PF1_1', 'should fail due to unique index');
ERROR: Cannot insert a duplicate key into a unique index
QUERY: update PSlot set backlink = 'WS.not.there' where slotname = 'PS.base.a1';
--- 1275,1285 ----
QUERY: insert into IFace values ('IF', 'orion', 'eth0', 'WS.002.1b');
QUERY: update PSlot set slotlink = 'HS.base.hub1.1' where slotname = 'PS.base.b2';
QUERY: select * from PField_v1 where pfname = 'PF0_1' order by slotname;
! NOTICE: plpgsql: ERROR during compile of wslot_slotlink_view near line 1
! ERROR: parse error at or near "q0xe2&^H^F"
QUERY: select * from PField_v1 where pfname = 'PF0_2' order by slotname;
! NOTICE: plpgsql: ERROR during compile of wslot_slotlink_view near line 1
! ERROR: parse error at or near "q0xe2&^H^F"
QUERY: insert into PField values ('PF1_1', 'should fail due to unique index');
ERROR: Cannot insert a duplicate key into a unique index
QUERY: update PSlot set backlink = 'WS.not.there' where slotname = 'PS.base.a1';
----------------------
I also tried this with yacc (the above is with bison 1.28). Very similar results.
Any suggestions? Thanks in advance...
> /usr/local/pgsql.new/bin/postmaster: can't resolve symbol 'plpgsql_yylineno' > ERROR: Load of file /usr/local/pgsql.new/lib/plpgsql.so failed: Unable to resolve symbol > > (I should mention that all of these outputs are cut-and-paste from vi's of the log > files, so control characters are "nicer" than they actually are in those files.) > > So I changed one line in scan.l to make sure plpgsql_yylineno was resolved, and > now it *mostly* works. > > The new problem is that plpgsql is still giving an error: > > Again, here's the relevant portion of the postmaster output: > > I also tried this with yacc (the above is with bison 1.28). Very similar results. > > Any suggestions? Thanks in advance... 6.5.2 should have allowed you to use either bison or yacc. I am running bsdi 4.0, but have never fooled around with plpgsql. -- Bruce Momjian | http://www.op.net/~candle maillist@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
>> Any suggestions? Thanks in advance... > >6.5.2 should have allowed you to use either bison or yacc. I am running >bsdi 4.0, but have never fooled around with plpgsql. > Thanks for chiming in... It otherwise seems to do fine (at least on the regression tests), but it does fail the plpgsql regression test, and I need plpgsql. I'm startled that you think that either bison or yacc would work. Out of the box, every plpgsql invocation fails (and thus everything in the plpgsql regression test) with the unresolved symbol error. Does a virgin 6.5.2 install pass the plpgsql regression test on your 4.0 bsdi box? Thanks.
> >> Any suggestions? Thanks in advance... > > > >6.5.2 should have allowed you to use either bison or yacc. I am running > >bsdi 4.0, but have never fooled around with plpgsql. > > > > Thanks for chiming in... > > It otherwise seems to do fine (at least on the regression > tests), but it does fail the plpgsql regression test, and I need plpgsql. > > I'm startled that you think that either bison or yacc would work. > Out of the box, every plpgsql invocation fails (and thus everything in > the plpgsql regression test) with the unresolved symbol error. > > Does a virgin 6.5.2 install pass the plpgsql regression test on your > 4.0 bsdi box? Thanks. > OK, I see it now: ERROR: Load of file /u/pg/lib/plpgsql.so failed: Unable to resolve symbol ./bin/postmaster: can't resolve symbol 'plpgsql_yylineno' Not sure about the cause. I see the several references to that variable as extern, but no non-extern references. Does BSDI handle this differently than other OS's? If a library has no non-external definition of a variable, a reference to the shared library would cause such an error as above, right? I am attaching a patch which defines plpgsql_yylineno as non-extern in one of the files. I am applying this to the current source tree too. That seems to fix most of the problems on bsdi. I see in the regression tests some strange stuff like: QUERY: select * from PField_v1 where pfname = 'PF0_1' order by slotname; NOTICE: plpgsql: ERROR during compile of wslot_slotlink_view near line 1 ERROR: parse error at or near "qR^F" Not sure what is causing that. My guess is that the there is still a problem with the parser internals referenced by plpgsql on bsdi. Please try my patch, and let me know if it improves things. Jan, any ideas? -- Bruce Momjian | http://www.op.net/~candle maillist@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 *** ./pl/plpgsql/src/pl_comp.c.orig Sun Sep 19 21:48:24 1999 --- ./pl/plpgsql/src/pl_comp.c Sun Sep 19 21:48:34 1999 *************** *** 68,74 **** * ---------- */ extern PLPGSQL_YYSTYPE plpgsql_yylval; ! extern int plpgsql_yylineno; extern char plpgsql_yytext[]; void plpgsql_yyerror(const char *s); --- 68,74 ---- * ---------- */ extern PLPGSQL_YYSTYPE plpgsql_yylval; ! int plpgsql_yylineno; extern char plpgsql_yytext[]; void plpgsql_yyerror(const char *s);
Thanks -- I did a similar change, which had similar results. I'm afraid I can't be of any help on the question of how BSDI handles shared libraries. I don't currently have a support contract with them, so I don't have a graceful "in" to ask them. I would say you have now duplicated the problem I was asking about, and if someone can solve it, I'll be a very happy fella. >Not sure what is causing that. My guess is that the there is still a >problem with the parser internals referenced by plpgsql on bsdi. Please >try my patch, and let me know if it improves things. > >Jan, any ideas? >
> Thanks -- I did a similar change, which had similar results. > > I'm afraid I can't be of any help on the question of how > BSDI handles shared libraries. I don't currently have a support > contract with them, so I don't have a graceful "in" to ask them. > > I would say you have now duplicated the problem I was asking about, > and if someone can solve it, I'll be a very happy fella. Does the new patch make it work, or just fail in a different way? -- Bruce Momjian | http://www.op.net/~candle maillist@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
>> Thanks -- I did a similar change, which had similar results.
>>
>> I'm afraid I can't be of any help on the question of how
>> BSDI handles shared libraries. I don't currently have a support
>> contract with them, so I don't have a graceful "in" to ask them.
>>
>> I would say you have now duplicated the problem I was asking about,
>> and if someone can solve it, I'll be a very happy fella.
>
>Does the new patch make it work, or just fail in a different way?
Hmmm... I might have missed a message, but if by "the new patch" you
mean the patch that declares yyline in pl_comp.c, then the way to
put it is that I get the same failure you do: plpgsql regression
test fails with the same (or nearly the same) error message you
got. The only difference between our patches is that you got rid
of the "extern" in pl_comp.c and I did it in scan.l.
Or, to put it another way:
Virgin 6.5.2 on BSDI 4.0:
Regresion test yields this error in the postmaster output on every
attempt to use plpgsql:
/usr/local/pgsql.new/bin/postmaster: can't resolve symbol 'plpgsql_yylineno'
ERROR: Load of file /usr/local/pgsql.new/lib/plpgsql.so failed: Unable to resolve symbol
I then came up with the patch of removing the "extern" from the declaration
of plpgsql_yylineno in scan.l (actually, it's called "yylineno" there and
changed later. Call that "Nat Patch #1"
You came up with a similar patch with identical consequences: you got
rid of the "extern" from the delcaration of plpgsql_yylineno in
pl_comp.c. Call this "Bruce Patch #1".
6.5.2 with Nat Patch #1 OR Bruce patch #1 fixes *most* of the
plpgsql errors, but the plpgsql regression still fails, in a smaller way:
you get these errors on postmaster output:
...
ERROR: Relation 'tmp' does not have attribute 'k'
NOTICE: plpgsql: ERROR during compile of wslot_slotlink_view near line 1
ERROR: syntax error at or near "q0xf2&^H^F"
DEBUG: Last error occured while executing PL/pgSQL function pslot_backlink_view
DEBUG: line 1 at return
NOTICE: plpgsql: ERROR during compile of wslot_slotlink_view near line 1
ERROR: syntax error at or near "q0xf2&^H^F"
DEBUG: Last error occured while executing PL/pgSQL function pslot_backlink_view
DEBUG: line 1 at return
and the regression.diffs file contains this:
*** expected/plpgsql.out Wed Sep 30 23:38:35 1998
--- results/plpgsql.out Sun Sep 19 01:48:14 1999
***************
*** 1275,1319 ****
QUERY: insert into IFace values ('IF', 'orion', 'eth0', 'WS.002.1b');
QUERY: update PSlot set slotlink = 'HS.base.hub1.1' where slotname = 'PS.base.b2';
QUERY: select * from PField_v1 where pfname = 'PF0_1' order by slotname;
! pfname|slotname |backside |patch
!
------+--------------------+--------------------------------------------------------+---------------------------------------------
! PF0_1 |PS.base.a1 |WS.001.1a in room 001 -> Phone PH.hc001 (Hicom standard)|PS.base.ta1 -> Phone line -0
(Centralcall)
! PF0_1 |PS.base.a2 |WS.001.1b in room 001 -> - |-
! PF0_1 |PS.base.a3 |WS.001.2a in room 001 -> Phone PH.fax001 (Canon fax) |PS.base.ta2 -> Phone line -501
(Faxentrance)
! PF0_1 |PS.base.a4 |WS.001.2b in room 001 -> - |-
! PF0_1 |PS.base.a5 |WS.001.3a in room 001 -> - |-
! PF0_1 |PS.base.a6 |WS.001.3b in room 001 -> - |-
! PF0_1 |PS.base.b1 |WS.002.1a in room 002 -> Phone PH.hc002 (Hicom standard)|PS.base.ta5 -> Phone line -103
! PF0_1 |PS.base.b2 |WS.002.1b in room 002 -> orion IF eth0 (PC) |Patchfield PF0_1 hub slot 1
! PF0_1 |PS.base.b3 |WS.002.2a in room 002 -> Phone PH.hc003 (Hicom standard)|PS.base.tb2 -> Phone line -106
! PF0_1 |PS.base.b4 |WS.002.2b in room 002 -> - |-
! PF0_1 |PS.base.b5 |WS.002.3a in room 002 -> - |-
! PF0_1 |PS.base.b6 |WS.002.3b in room 002 -> - |-
! PF0_1 |PS.base.c1 |WS.003.1a in room 003 -> - |-
! PF0_1 |PS.base.c2 |WS.003.1b in room 003 -> - |-
! PF0_1 |PS.base.c3 |WS.003.2a in room 003 -> - |-
! PF0_1 |PS.base.c4 |WS.003.2b in room 003 -> - |-
! PF0_1 |PS.base.c5 |WS.003.3a in room 003 -> - |-
! PF0_1 |PS.base.c6 |WS.003.3b in room 003 -> - |-
! (18 rows)
!
QUERY: select * from PField_v1 where pfname = 'PF0_2' order by slotname;
! pfname|slotname |backside |patch
!
------+--------------------+------------------------------+----------------------------------------------------------------------
! PF0_2 |PS.base.ta1 |Phone line -0 (Central call) |PS.base.a1 -> WS.001.1a in room 001 -> Phone PH.hc001
(Hicomstandard)
! PF0_2 |PS.base.ta2 |Phone line -501 (Fax entrance)|PS.base.a3 -> WS.001.2a in room 001 -> Phone PH.fax001
(Canonfax)
! PF0_2 |PS.base.ta3 |Phone line -102 |-
! PF0_2 |PS.base.ta4 |- |-
! PF0_2 |PS.base.ta5 |Phone line -103 |PS.base.b1 -> WS.002.1a in room 002 -> Phone PH.hc002
(Hicomstandard)
! PF0_2 |PS.base.ta6 |Phone line -104 |-
! PF0_2 |PS.base.tb1 |- |-
! PF0_2 |PS.base.tb2 |Phone line -106 |PS.base.b3 -> WS.002.2a in room 002 -> Phone PH.hc003
(Hicomstandard)
! PF0_2 |PS.base.tb3 |Phone line -108 |-
! PF0_2 |PS.base.tb4 |Phone line -109 |-
! PF0_2 |PS.base.tb5 |Phone line -121 |-
! PF0_2 |PS.base.tb6 |Phone line -122 |-
! (12 rows)
!
QUERY: insert into PField values ('PF1_1', 'should fail due to unique index');
ERROR: Cannot insert a duplicate key into a unique index
QUERY: update PSlot set backlink = 'WS.not.there' where slotname = 'PS.base.a1';
--- 1275,1285 ----
QUERY: insert into IFace values ('IF', 'orion', 'eth0', 'WS.002.1b');
QUERY: update PSlot set slotlink = 'HS.base.hub1.1' where slotname = 'PS.base.b2';
QUERY: select * from PField_v1 where pfname = 'PF0_1' order by slotname;
! NOTICE: plpgsql: ERROR during compile of wslot_slotlink_view near line 1
! ERROR: parse error at or near "q0xe2&^H^F"
QUERY: select * from PField_v1 where pfname = 'PF0_2' order by slotname;
! NOTICE: plpgsql: ERROR during compile of wslot_slotlink_view near line 1
! ERROR: parse error at or near "q0xe2&^H^F"
QUERY: insert into PField values ('PF1_1', 'should fail due to unique index');
ERROR: Cannot insert a duplicate key into a unique index
QUERY: update PSlot set backlink = 'WS.not.there' where slotname = 'PS.base.a1';
----------------------
So, the remaining problem is to fix those errors. Now, it's possible
you sent "Bruce Patch #2", and I missed it. Did you?
Or do you still have the error from the regression test shown above?
If you do, then there's still work to do, but if you don't, I missed
something -- please send it again!
Thanks a lot for the help!
I am no closer to fixing this, but have added it to our TODO list. > Thanks -- I did a similar change, which had similar results. > > I'm afraid I can't be of any help on the question of how > BSDI handles shared libraries. I don't currently have a support > contract with them, so I don't have a graceful "in" to ask them. > > I would say you have now duplicated the problem I was asking about, > and if someone can solve it, I'll be a very happy fella. > > >Not sure what is causing that. My guess is that the there is still a > >problem with the parser internals referenced by plpgsql on bsdi. Please > >try my patch, and let me know if it improves things. > > > >Jan, any ideas? > > > -- Bruce Momjian | http://www.op.net/~candle maillist@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
Very much obliged! I'll be watching the mailing lists, but if anyone does solve it, and happens to remember, please drop me a note. If there's anything more I can do to help, let me know. Thanks! > >I am no closer to fixing this, but have added it to our TODO list. > > >> Thanks -- I did a similar change, which had similar results. >> >> I'm afraid I can't be of any help on the question of how >> BSDI handles shared libraries. I don't currently have a support >> contract with them, so I don't have a graceful "in" to ask them. >> >> I would say you have now duplicated the problem I was asking about, >> and if someone can solve it, I'll be a very happy fella. >> >> >Not sure what is causing that. My guess is that the there is still a >> >problem with the parser internals referenced by plpgsql on bsdi. Please >> >try my patch, and let me know if it improves things. >> > >> >Jan, any ideas? >> > >> > > >-- > Bruce Momjian | http://www.op.net/~candle > maillist@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
> Very much obliged! I'll be watching the mailing lists, but if anyone > does solve it, and happens to remember, please drop me a note. > > If there's anything more I can do to help, let me know. Thanks! I am sure I can get it fixed by 6.6. > > > > >I am no closer to fixing this, but have added it to our TODO list. > > > > > >> Thanks -- I did a similar change, which had similar results. > >> > >> I'm afraid I can't be of any help on the question of how > >> BSDI handles shared libraries. I don't currently have a support > >> contract with them, so I don't have a graceful "in" to ask them. > >> > >> I would say you have now duplicated the problem I was asking about, > >> and if someone can solve it, I'll be a very happy fella. > >> > >> >Not sure what is causing that. My guess is that the there is still a > >> >problem with the parser internals referenced by plpgsql on bsdi. Please > >> >try my patch, and let me know if it improves things. > >> > > >> >Jan, any ideas? > >> > > >> > > > > > >-- > > Bruce Momjian | http://www.op.net/~candle > > maillist@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 > -- Bruce Momjian | http://www.op.net/~candle maillist@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