On Thu, Sep 3, 2015 at 1:46 AM, Jim Nasby <
Jim.Nasby@bluetreble.com> wrote:
> The double set of exceptions seems to be critical; if instead of calling
> tf.get(invoice) (which recursively does tf.get(customer)) I define the
> cursor to call tf.get(customer) directly there's no assert.
Finally I have been able to crack down the problem, and it can be reproduced with the following test case for example:
BEGIN;
CREATE OR REPLACE FUNCTION create_self_tab() RETURNS text
LANGUAGE plpgsql AS $$
BEGIN
CREATE TEMP TABLE new_table ON COMMIT DROP AS SELECT create_self_tab();
RETURN 'foo';
END $$;
DECLARE h CURSOR FOR SELECT create_self_tab();
SAVEPOINT self_tab_point;
FETCH h; -- error
COMMIT;
When fetching the first tuple, the transaction status is cleaned up to the savepoint because the call actually fails in the second loop at the temporary relation exists, but it happens that the temporary table that has been created tried to be cleanup up but it is still referenced, causing the assertion failure. So that's not related to the use of the exception blocks. What directed me to the SAVEPOINT causing the issue is the use of ON_ERROR_ROLLBACK in the test case Jim proposed. I don't have a patch at hand yet, still now things are easier to test.
