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