Re: exec_execute_message crash

> I tried this but didn't have any luck crashing the backend.  libpq gets
> tremendously confused by the extra ReadyForQuery responses, which is
> unsurprising.  The postmaster log shows
> 
> LOG:  could not send data to client: Broken pipe
> ERROR:  relation "foo" does not exist at character 15
> STATEMENT:  SELECT * FROM foo
> ERROR:  unnamed prepared statement does not exist
> ERROR:  current transaction is aborted, commands ignored until end of transaction block
> ERROR:  current transaction is aborted, commands ignored until end of transaction block
> STATEMENT:  SELECT NULL , n.nspname,  ct.relname,  a.attname,  a.attnum,  ci.relname FROM pg_catalog.pg_namespace n,
pg_catalog.pg_classct, pg_catalog.pg_class ci, pg_catalog.pg_attribute a, pg_catalog.pg_index i  WHERE
ct.oid=i.indrelidAND ci.oid=i.indexrelid  AND a.attrelid=ci.oid AND i.indisprimary  AND ct.relname =
'mst_Ucompany_feature_setting' AND ct.relnamespace = n.oid  AND n.nspname = 'foo' ORDER BY 1, 2, 3
 
> 
> So the "unnamed prepared statement does not exist" bit seems to be
> related to what you are talking about, but it doesn't actually fail.

I have put some debugging codes to make sure that portal->cplan and
portal->stmts belong to the same memory context by calling
GetMemoryChunkContext and surely they did. It appears that the memory
was surely deleted by MemeoryContextDelete in ReleaseCachedPlan. Also
I defined CLOBBER_FREED_MEMORY in aset.c to fill with 0x7f the freed
memory. Strange thing was portal->smts was not clobbered by 0x7f.
It seems I have missed something here...
--
Tatsuo Ishii
SRA OSS, Inc. Japan