UPDATE test SET broken='1234', works='1234',
alsoworks='1234';
INFO: ("TD={'relid': '3928912', 'old': {'alsoworks': 'test', 'broken': 1,
'works': 'test'}, 'name': 'tes
d have
already run smack into the caching problem you described. :-(
--
Arthur Ward
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
tached patch; please confirm it works for you.
Applied successfully to 7.3.3 and the bug in question is fixed for my
situation. Thanks a bunch for the quick fix!
Now to implement the workaround for the plpython trigger &
rowtype caching problem...
--
Arthur Ward
---(end
I have a table with a plpython trigger defined on it in 7.3.4. I've
dropped a column from that table, and now I cannot get a plpython trigger
to run at all on that table. I've dropped both the trigger and function
and recreated them from scratch (not using "create or replace"), and I
still get the
> "Arthur Ward" <[EMAIL PROTECTED]> writes:
>> I have a table with a plpython trigger defined on it in 7.3.4. I've
>> dropped a column from that table, and now I cannot get a plpython
>> trigger
>> to run at all on that table.
>
> Would you tr
I was a bit stunned last night when I found this in the server logs for a
7.4RC2 installation:
Nov 24 20:37:18 x pg_autovacuum: [2003-11-24 08:37:18 PM] Performing:
VACUUM ANALYZE "clients"."x"
Nov 24 20:37:19 x postgres: [13904] PANIC: insufficient room in FSM
Nov 24 20:37:19 x postgres: STATEME
> "Arthur Ward" <[EMAIL PROTECTED]> writes:
>> I was a bit stunned last night when I found this in the server logs for
>> a
>> 7.4RC2 installation:
>
>> Nov 24 20:37:18 x pg_autovacuum: [2003-11-24 08:37:18 PM] Performing:
>> VACUUM ANALYZE
