On 02.02.2011 17:52, Kevin Grittner wrote:
I found two problems with this, and I'm not sure how to handle
either. If we can figure out an approach, I'm happy to work on it.
(1) We don't have much in the way of detail yet. I put a different
detail message on each, so that there is more evidence, hopefully at
least somewhat comprehensible to an educated user, about how the
cancelled transaction fit into the dangerous pattern of access among
transactions. Ultimately, I hope we can improve these messages to
include such detail as table names in many circumstances, but that's
not 9.1 material. What I did include, when it was easily available,
was another xid involved in the conflict. These are not matching
from one test to the next.
(2) The NOTICE lines for implicit index creation pop up at odd times
in the output, like in the middle of a SQL statement. It looks like
these are piling up in a buffer somewhere and getting dumped into the
output when the buffer fills. They are actually showing up at
exactly the same point on each run, but I doubt that we can count on
that for all platforms, and even if we could -- it's kinda ugly.
Perhaps we should change the client logging level to suppress these?
They're not really important here.
So, I think (2) is probably easy, but I don't see how we can deal
with (1) as easily. Suppress detail? Filter to change the xid
number to some literal?
Suppressing detail seems easiest. AFAICS all the variable parts are in
errdetail.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
