No. Here is the offending SP:
CREATE OR REPLACE FUNCTION update_my_cache() RETURNS void AS '
BEGIN
TRUNCATE TABLE my_cache_table;
INSERT INTO my_cache_table SELECT * FROM
get_my_stuff_to_fill_cache_table();
RETURN;
END
' LANGUAGE plpgsql;
I've checked the SP get_my_stuff_to_fill_cache_table() that is run from
within update_my_cache() and it does not cause locks. So it seems
something else about the update_my_cache() SP is causing this access
exclusive lock which prevents anything from even dirty reading the
table for the entire time it executes (roughly 10 seconds);
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
