"Sergey E. Koposov" <[EMAIL PROTECTED]> writes:
> I'm also sending The output from strace (during the execution of the test
> program which I have sent before) showing what jdbc is sending to the
> backend.
Great, I was just going to ask for that.
I can reproduce it in HEAD pretty trivially using libpq:
res = PQexecParams(conn,
"BEGIN",
0, /* no params */
NULL, /* let the backend deduce param type */
NULL,
NULL, /* don't need param lengths since text */
NULL, /* default to all text params */
0); /* ask for text results */
if (PQresultStatus(res) != PGRES_COMMAND_OK)
{
fprintf(stderr, "BEGIN failed: %s", PQerrorMessage(conn));
PQclear(res);
exit_nicely(conn);
}
printf("cmd status = '%s'\n", PQcmdStatus(res));
PQclear(res);
res = PQexecParams(conn,
"ROLLBACK",
0, /* no params */
NULL, /* let the backend deduce param type */
NULL,
NULL, /* don't need param lengths since text */
NULL, /* default to all text params */
0); /* ask for text results */
if (PQresultStatus(res) != PGRES_COMMAND_OK)
{
fprintf(stderr, "ROLLBACK failed: %s", PQerrorMessage(conn));
PQclear(res);
exit_nicely(conn);
}
printf("cmd status = '%s'\n", PQcmdStatus(res));
PQclear(res);
It turns out that COMMIT dies just the same way. The problem is that
any transaction-exiting command destroys portals at the
finish_xact_command step, but the log_duration code is expecting the
portal to still be there afterwards.
We could "fix" this by emitting the log message before calling
finish_xact_command, but I think that would result in seriously
underreporting the time required for a COMMIT. Probably the right fix
is to copy the data we might need out of the Portal before committing.
Or, if people don't like the overhead for that, we could reduce the
amount of info included in the log message ... but probably that
would make it unhelpful :-(
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
