Forum OpenACS Q&A: openacs 3.2.5 on 7.1.1 error
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)
So I installed PG without Python built in. Everything worked. I
created mydb and loaded:
./load-geo-tables mydb (worked fine)
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
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
I looks like it cannot create more than x tables at once....
What is broken???
Is it a problem with 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.
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.
So ... keep tuned and prepare to patch!
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.
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.
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.
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?
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).
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.
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...
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....
--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.