Re: Fwd: Core dump with nested CREATE TEMP TABLE

On Wed, Sep 2, 2015 at 6:13 AM, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com> wrote:
> On 9/1/15 11:59 PM, Michael Paquier wrote:
>>
>> On Wed, Sep 2, 2015 at 12:59 PM, Jim Nasby wrote:
>>>
>>> On 9/1/15 8:42 PM, Michael Paquier wrote:
>>> The crash is triggered by having an exception raised in this particular
>>> call
>>> stack. Since there's no syntax error in master/0.2.1, there's no assert
>>> failure either. Were you running asserts?
>>
>>
>> I thought I was, but visibly it was mistaken. So, after re-rolling
>> configure, I have been able to reproduce the crash, and as far as I
>> can see all supported versions are impacted. I tested down to 9.1
>> where extensions were introduced, and the stack trace, as well as the
>> assertion failing are the same, similar to what Jim has reported. I am
>> just digging more into this thing now.
>
>
> I just had a theory that reference counts were messed up because there was
> both a temp table and a real table with the same name. Turns out that's
not
> the case, but I do now know that the assert is failing for the reference
> count on the temp table.

Yes, that's what I have been looking at actually by having some markers in
relcache.c. The reference count of this relation get incremented here:
LOG: increment ref count relation: invoice_0000000003, rd_refcnt: 1
CONTEXT: SQL statement "
CREATE TEMP TABLE invoice_0000000003 ON COMMIT DROP AS
WITH i AS (
INSERT INTO invoice VALUES(
DEFAULT
, (tf.get( NULL::customer, 'insert' )).customer_id
, current_date
, current_date + 30
) RETURNING *
)
SELECT *
FROM i
"
PL/pgSQL function tf.get(anyelement,text) line 29 at EXECUTE
PL/pgSQL function results_eq(refcursor,refcursor,text) line 11 at
FETCH
PL/pgSQL function results_eq(text,text,text) line 9 at assignment
STATEMENT: SELECT results_eq(
$$SELECT * FROM tf.get( NULL::invoice, 'base' )$$
, $$VALUES( 1, 1, current_date, current_date + 30 )$$
, 'invoice factory output'
);
And it gets cleared here without being decremented when cleaning up the
second exception:
LOG: clear relation: invoice_0000000003, rd_refcnt: 1
CONTEXT: PL/pgSQL function results_eq(refcursor,refcursor,text) line 11
during exception cleanup
PL/pgSQL function results_eq(text,text,text) line 9 at assignment
STATEMENT: SELECT results_eq(
$$SELECT * FROM tf.get( NULL::invoice, 'base' )$$
, $$VALUES( 1, 1, current_date, current_date + 30 )$$
, 'invoice factory output'
);
--
Michael