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
Tatsuo Ishii is...@postgresql.org writes:
Done. Inclded are C test program along with modified fe-exec.c.
The modification made to fe-exec.c is sending Sync after Parse, Bind
and Describe. Pgpool-II does this in order to get current transaction
status.
I tried this but didn't have any luck
While inspecting a complain from a pgpool user, I found that
PostgreSQL crushes with following statck trace:
#0 0x0826436a in list_length (l=0xaabe4e28)
at ../../../src/include/nodes/pg_list.h:94
#1 0x08262168 in IsTransactionStmtList (parseTrees=0xaabe4e28)
at postgres.c:2429
Tatsuo Ishii wrote:
! if (!PortalIsValid(portal) || (PortalIsValid(portal) portal-cleanup
== NULL))
Surely the second call to PortalIsValid() is redundant.
if (( !PortalIsValid(portal)) || portal-cleanup == NULL)
should do it, no?
cheers
andrew
--
Sent via
Tatsuo Ishii wrote:
! if (!PortalIsValid(portal) || (PortalIsValid(portal) portal-cleanup
== NULL))
Surely the second call to PortalIsValid() is redundant.
if (( !PortalIsValid(portal)) || portal-cleanup == NULL)
should do it, no?
Oops. You are right.
--
Tatsuo Ishii is...@postgresql.org writes:
parse causes transaction to abort, which causes call to
AbortCurrentTransaction-AbortTransaction-AtAbort_portals-ReleaseCachedPlan.
It
calls ReleaseCachePlan(portal-cplan). ReleaseCachePlan calls
MemoryContextDelete(plan-context) which destroys both
This is just a kluge, and a rather bad one I think. The real problem
here is that AtAbort_Portals destroys the portal contents and doesn't
do anything to record the fact. It should probably be putting the
portal into PORTAL_FAILED state, and what exec_execute_message ought
to be doing is
