Re: Fwd: Core dump with nested CREATE TEMP TABLE
От | Jim Nasby |
---|---|
Тема | Re: Fwd: Core dump with nested CREATE TEMP TABLE |
Дата | |
Msg-id | 55E67410.7000706@BlueTreble.com обсуждение исходный текст |
Ответ на | Re: Fwd: Core dump with nested CREATE TEMP TABLE (Michael Paquier <michael.paquier@gmail.com>) |
Ответы |
Re: Fwd: Core dump with nested CREATE TEMP TABLE
|
Список | pgsql-hackers |
On 9/1/15 8:42 PM, Michael Paquier wrote: > On Wed, Sep 2, 2015 at 9:39 AM, Michael Paquier > <michael.paquier@gmail.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
В списке pgsql-hackers по дате отправления: