Forum OpenACS Q&A: openacs 3.2.5 on 7.1.1 error

Posted by David Kuczek on 05/06/01 07:58 PM

I just installed PG 7.1.1 on a RH 6.2 system.

The first difficulty I had was that during compilation the python
configuration file couldn't be found. The compilation process was
looking for a file inside (I guess it was)
HomeForPython/configuration/TheFile.so.in

So I installed PG without Python built in. Everything worked. I
created mydb and loaded:

./load-geo-tables mydb (worked fine)

then loaded

psql -f load-data-model.sql mydb

The load-data-model.sql got a bit problematic. It loaded everything up
to homepage.sql and then:

psql:homepage.sql:373: pqReadData() -- backend closed the channel
unexpectedly.
This probably means the backend terminated abnormally
before or while processing the request.
psql:homepage.sql:373: connection to server was lost

Then I commented homepage.sql out and it stoped with the same error at
survey-simple.sql

I looks like it cannot create more than x tables at once....

What is broken???

Is it a problem with Python?

Thanks

2: Response to openacs 3.2.5 on 7.1.1 error (response to 1)

Posted by Don Baccus on 05/06/01 10:50 PM

It is not a problem with Python, OpenACS 3.2.5 only requires PL/pgSQL. You can do a "make distclean" then reconfigure without Python like this:

./config --without-python

I think (check the docs to make sure I've got the switch right, or heck, just try it).

It appears to be a problem in generating new WAL files when your current WAL file fills up (thus the "it can only do so much and then dies" problem).

Do the steps I mentioned above and add "--debug" to your config (again, you may need to check docs). Then check your postmaster log to see what the problem is. If you're not logging postmaster output you can shut it down and just run it from a shell window and watch the output.

The cause could be something as incorrect permissions on a directory ... or it could be a real bug in PG 7.1.1 (hope not!) Feel free to post the debug log here, hopefully it will tell us something useful that, if necessary, can be sent of the the PG development folk.

3: Response to openacs 3.2.5 on 7.1.1 error (response to 1)

Posted by Connie Hentosh on 05/07/01 08:37 PM

I am getting the same error on OpenBSD 2.8... I am also trying to debug it now.

4: Response to openacs 3.2.5 on 7.1.1 error (response to 1)

Posted by Connie Hentosh on 05/07/01 10:24 PM

Okay... using 7.1.1. built with

./configure --enable-debug

on OpenBSD 2.8

Loading the data model causes it to crash with a Signal 11, Segmentation fault in SPI_gettypeid at spi.c:501. Looks like tupdesc is null.

5: Response to openacs 3.2.5 on 7.1.1 error (response to 1)

Posted by Don Baccus on 05/08/01 02:29 AM

Just an addendum...Connie and I swapped a couple of private e-mails and she's bundled stuff up and submitted it to pg-bugs (before I asked, even, I think!) If she doesn't get a response in a day or so she'll bug Tom Lane directly.

So ... keep tuned and prepare to patch!

6: Response to openacs 3.2.5 on 7.1.1 error (response to 1)

Posted by Connie Hentosh on 05/08/01 02:41 AM

I have gotten a response from Tom over on the pgsql-bug list. He doesn't have a solution yet but was able to recreate the problem. He had this to say in his note:

Hm.  I notice that postgres.sql hardwires the location of the plpgsql
handler:

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

create trusted procedural language 'plpgsql'
HANDLER plpgsql_call_handler
LANCOMPILER 'PL/pgSQL';

If this were to suck in a wrong-version copy of plpgsql.so (and yes,
I think 7.1 vs 7.1.1 could be wrong version) then that could cause
failures.

postgres-pgtcl.sql is equally unwise about the pltcl handler.

This is *not* the source of your problem, since I was able to
reproduce the crash even with a proper "createlang plpgsql" used
instead of the bogus commands.  But you might want to pass on the
observation to the OpenACS guys.

7: Response to openacs 3.2.5 on 7.1.1 error (response to 1)

Posted by Connie Hentosh on 05/08/01 03:10 AM

Looks like the problem was found. The patch will appear shortly.

I also asked about what should be the proper alternative to the issue of the hardcoded path, since it seems that thier docs show that as an example.

8: Response to openacs 3.2.5 on 7.1.1 error (response to 1)

Posted by Connie Hentosh on 05/08/01 05:10 AM

Well it seems the correct method is not to hardcode the path but to use the createlang script. For now... plans in the future include making the DB use a search path to load the file from the correct library dir.

As a work around for this above issue you can fetch version 1.40 of src/pl/plpgsql/src/pl_exec.c. The comments from the last change of the file that caused the problem suggest that this will work fine for tables that haven't been altered or inherited (the reason for the original patch that caused this problem). I have tested it and it works. **DISCLAIMER** This is not the official patch or even suggested patch from the pg team. Just my tinkering.

9: Response to openacs 3.2.5 on 7.1.1 error (response to 1)

Posted by David Kuczek on 05/08/01 12:27 PM

Where do such patches usually appear? In the cvs of postgres?

To understand the process of compilation and installation better I would have a question:

Postgres is installing all the necessary libraries and tools in /usr/local/pgsql?! Is this correct or does it write anything into other directories?

If I installed Postgres in the default directory and I want to uninstall or delete it, is it normal to just remove the /pgsql directory or is there another way to do this?

10: Response to openacs 3.2.5 on 7.1.1 error (response to 1)

Posted by Don Baccus on 05/08/01 01:17 PM

Connie - we are recommending that people use "createlang" and should check to make sure the documents reflect that. We should've ripped out the offending lines in postgres.sql, that was an oversight on my part since I'd figured out that "createlang" was the right thing to do months ago.

11: Response to openacs 3.2.5 on 7.1.1 error (response to 1)

Posted by Connie Hentosh on 05/08/01 04:34 PM

David, yes all code changes appear in Postgresql's CVS. If you checkout branch REL7_1_STABLE it has a patch in it now. There wasn't an announcement in the bugs list, but I noticed the change in CVS. I did a little testing and it appears to work well.

Don, The only mention I see of createlang in the documentation is in www/doc/bboard.html. This if for the pltcl search that you created. I don't see any mention for plpgsql. Also, it is not mentioned for either language in the OpenACS installation Guide at http://openacs.org/doc/openacs/install/ (which I found very handy).

12: Response to openacs 3.2.5 on 7.1.1 error (response to 1)

Posted by David Kuczek on 05/08/01 05:03 PM

Hello Connie,

I just checked out the Postgres CVS path and saw what you saw "pl_exec.c changed 13hours ago"...

I just replace this file with the one that is sitting inside the tared 7.1.1 version and then compile it once again, right?

By the way can I check out all the recent patches on one page via cvs? That would be quite valueable to see where else patches were submitted.

13: Response to openacs 3.2.5 on 7.1.1 error (response to 1)

Posted by Brad Ford on 05/13/01 06:37 AM

I just had the same problem on my install - ACS 3.2.5 + AOLserver 3.2 +acsMod10 + PG 7.1.1 + RH 6.2. Tanked at the exact same spot. I did a search on 'load data model problem' and ended up here. Followed the advice, downloaded the patched pl_exec.c file and copied it to the /src/pl/pgsql (if I remember correctly...) directory, repacing the old file. Did a make distclean, then a ./configure --with-x --without-python, another make and finally a make install. Loaded everything like a charm. Thanks for the help.

Just a thought - I downloaded 7.1.1 yesterday (May 12) and the patch was not rolled into the distribution. It would save a bunch of hassle for anyone attempting a new installation if a note was added to the install docs: 'open the pl_exec.c file in a text editor and make sure it is either version 1.4.12 or 1.4.2 or higher'. Either that or convince the postgresql people to roll it into the source code being distributed on the mirror sites...

14: Response to openacs 3.2.5 on 7.1.1 error (response to 1)

Posted by David Kuczek on 05/13/01 09:52 AM

Hello Brad,

people should wait some more days for the 7.1.2 release. The pg_dump problem shall be fixed by then as well. Lamar Owen stated some days ago that the PG-team somehow has bad luck with x.y.1 releases...

You can check out those kind of discussions at the postgresql hackers list....

15: PostgreSQL 7.1.2 out (response to 1)

Posted by Brian Baquiran on 06/04/01 11:01 AM

I just downloaded and installed PostgreSQL 7.1.2. 'psql -f load-data-model.sql mydb' works fine after 'createlang plpgsql'.

16: Response to openacs 3.2.5 on 7.1.1 error (response to 1)

Posted by Roeland Lengers on 06/04/01 08:15 PM

I encountered the same error running on SuSE 7.1 (kernel 2.4). This bboard pointed me to the real problem: Postgresql 7.1.1 is not working properly. Redid my installation with version 7.1.2. Everything worked fine. Before you actually load the datamodel I suggest you make an addition to homepage.sql. All the way at the end of the file, add:

--drop function  hp_get_nh_member_count(integer);
create function  hp_get_nh_member_count(integer) returns integer as '
declare
        neighborhoodid alias for $1;
        counter         integer;
BEGIN
        select into counter count(*) from users_homepages
                where neighborhood_id = neighborhoodid;
        return counter;
END;
' language 'plpgsql';

And execute this create statement in psql. Otherwise the neighborhood functionality will not work.

17: Response to openacs 3.2.5 on 7.1.1 error (response to 1)

Posted by Vinod Kurup on 06/04/01 08:23 PM

There are a couple of other minor changes needed to get neighborhoods working. See this patch.