Re: Fwd: Core dump with nested CREATE TEMP TABLE

From: Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com>
To: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Fwd: Core dump with nested CREATE TEMP TABLE
Date: 2015-09-02 03:59:12
Message-ID: 55E67410.7000706@BlueTreble.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 9/1/15 8:42 PM, Michael Paquier wrote:
> On Wed, Sep 2, 2015 at 9:39 AM, Michael Paquier
> <michael(dot)paquier(at)gmail(dot)com> wrote:
>> On Wed, Sep 2, 2015 at 7:23 AM, Jim Nasby wrote:
>>> Well nuts, pretty sure that means the error isn't reproducing for you. :/ Do
>>> you maybe have unusual config options or postgresql.conf options?
>>
>> Yep. And I have found one reason why it was not working, I have been
>> using --extra-version with a custom string and the Makefile of
>> test_factory failed to detect that (you may want to use VERSION_NUM in
>> Makefile.global instead), leading to test_factory--0.1.1.sql to not be
>> installed as well.
>>
>> Even after fixing that, I am facing the same problem when running the test, aka:
>> psql:crash.sql:42: ERROR: 42703: column "c_data_table_name" does not exist
>> LINE 4: , c_data_table_name
>> And the same error show up, should I use the branch crash in the
>> github repo or your zip file, make test or make install/psql -f
>> crash.sql.
>>
>> test_factory is a jungle to me. Perhaps you could just extract a
>> self-contained test case? It does not matter if the file is long as
>> long as the problem can be easily reproduced.
>
> Mea culpa. It is possible to run crash.sql, with test_factory instead
> 0.2.1 installed in a cluster. So I picked it up from github on master
> branch, deployed it, and then crash.sql is able to run. However I was
> not able to reproduce a failure on master, REL9_4_STABLE and 9.4.1.
> Thoughts?

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? What configure line are
you using? I might be able to track this down to something particular to
my configure.
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2015-09-02 04:15:55 Re: [PATCH] SQL function to report log message
Previous Message Jaime Casanova 2015-09-02 02:21:36 Re: synchronous_commit = apply