Skip site navigation (1) Skip section navigation (2)

Re: [PORTS] plpgsql & bsdi 4.0

From: Nat Howard <nrh(at)pupworks(dot)com>
To: Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us>
Cc: Nat Howard <nrh(at)pupworks(dot)com>, pgsql-ports(at)postgreSQL(dot)org, Jan Wieck <jwieck(at)debis(dot)com>
Subject: Re: [PORTS] plpgsql & bsdi 4.0
Date: 1999-09-20 18:22:39
Message-ID: 199909201822.OAA16477@spot.pupworks.com (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-ports
>> 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 (Central call)
! 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 (Fax entrance)
! 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 (Hicom standard)
! PF0_2 |PS.base.ta2         |Phone line -501 (Fax entrance)|PS.base.a3 -> WS.001.2a in room 001 -> Phone PH.fax001 (Canon fax)
! 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 (Hicom standard)
! 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 (Hicom standard)
! 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!  




Responses

pgsql-ports by date

Next:From: sugarhDate: 1999-09-20 18:46:56
Subject: postgresql back-end would not start on FreeBSD v 2.2.7
Previous:From: AGRAGANSDate: 1999-09-20 17:23:44
Subject: Portage applicatif ESQL/C Informix sur POSTGRES ESQL/C

pgsql-hackers by date

Next:From: Peter MountDate: 1999-09-20 18:50:43
Subject: Re: [HACKERS] Status on Jan Wieck
Previous:From: Bruce MomjianDate: 1999-09-20 18:14:51
Subject: Re: [HACKERS] Status on Jan Wieck

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group