> 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