| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Fwd: Core dump with nested CREATE TEMP TABLE |
| Date: | 2015-08-29 16:31:48 |
| Message-ID: | 20150829163148.GD31526@awork2.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
On 2015-08-29 11:06:05 -0500, Jim Nasby wrote:
> Stack trace below. Relevant assert:
What exact revision is this on? Either there's some aggressive inlining
going on, or these lines don't entirely match up with HEAD.
That's compiled with optimization, isn't it? Could you compile with -O0?
Can you go up to
> > frame #19: 0x0000000116295f1f plpgsql.so`exec_stmt_block(estate=0x00007fff532c0090, block=0x00007fa3f53a21d0) + 2095 at pl_exec.c:1300
and do 'disass/m' to see where we actually are?
The area around #19 likely is the PG_CATCH inside exec_stmt_block. So
what's happening is that there's an exception raised, while handling the
previous exception. And apparently we're not doing that entirely
right. Besides the line numbers "during exception cleanup" hints at
that.
Greetings,
Andres Freund
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2015-08-29 16:36:03 | Re: On-demand running query plans using auto_explain and signals |
| Previous Message | Pavel Stehule | 2015-08-29 16:27:59 | Re: On-demand running query plans using auto_explain and signals |