On Wed, Sep 2, 2015 at 6:13 AM, Jim Nasby <jim.na...@bluetreble.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

Reply via email to