Forum OpenACS Q&A: openacs 3.2.5 on 7.1.1 error

./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.

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.

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.

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.

--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';