> 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_class ct, > pg_catalog.pg_class ci, pg_catalog.pg_attribute a, pg_catalog.pg_index i > WHERE ct.oid=i.indrelid AND 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
