On May 9, 2006, at 9:09 PM, Tom Lane wrote:
"Casey Duncan" <[EMAIL PROTECTED]> writes:
CREATE FUNCTION write_error_trigf() RETURNS trigger AS '
BEGIN
RAISE EXCEPTION ''Writes not allowed to this table on this
node'';
END;
' LANGUAGE plpgsql;
END; --Upgrade script
You did not show how this function is being used, but I'm wondering if
it is an AFTER trigger on inserts into ss? If so, the reason for the
out-of-memory failure might be accumulation of pending trigger event
records.
Without wishing to defend our lack of ability to spill trigger events
to disk, you probably wouldn't be happy with the performance if it did
work :-(. Consider making the trigger BEFORE instead of AFTER, so
that
there's not a need to remember a ton of pending trigger firings. I
don't
see any reason why this trigger needs to be AFTER.
That's good to know, but I think it's a red herring in this case. The
upgrade script creates this function, but it doesn't setup the
triggers themselves, another external script does that after the
upgrade. Basically we're creating a multi-database cluster where all
the dbs have the same schema, but you aren't supposed to write to
certain tables in certain nodes.
The script actually fails before the function is even defined anyhow,
on this statement:
INSERT INTO ss
(ss_id, name, ll_id, shared_ss_id, time_added,
shared_creator_id)
SELECT nextval('ss_id_seq'), s.name, lts.ll_id, s.ss_id,
lts.time_added, s.ll_id
FROM ss AS s, ll_to_ss AS lts
WHERE lts.ll_id != s.ll_id;
There are no triggers of any kind on ss. Basically this statement is
a step toward eliminating the ll_to_ss table (which was used for a
many-to-many between ll and ss) and creating a one-to-many between ll
and ss. This merges some portion of ll_to_ss with ss.
-Casey
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
