Re: [COMMITTERS] pgsql: Mark JSON error detail messages for translation. - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [COMMITTERS] pgsql: Mark JSON error detail messages for translation.
Date
Msg-id 11665.1339602940@sss.pgh.pa.us
Whole thread Raw
In response to Re: [COMMITTERS] pgsql: Mark JSON error detail messages for translation.  (Andres Freund <andres@2ndquadrant.com>)
Responses Re: [COMMITTERS] pgsql: Mark JSON error detail messages for translation.  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Andres Freund <andres@2ndquadrant.com> writes:
> On Wednesday, June 13, 2012 05:18:22 PM Robert Haas wrote:
>> According to my testing, the main cost of an exception block catching
>> a division-by-zero error is that of generating the error message,
>> primarily sprintf()-type stuff.  The cost of scanning a multi-megabyte
>> string seems likely to be much larger.

> True. I ignored that there doesn't have to be an xid assigned yet... I still 
> think its not very relevant though.

I don't think it's relevant either.  In the first place, I don't think
that errors occurring "multi megabytes" into a JSON blob are going to
occur often enough to be performance critical.  In the second place,
removing cycles from the non-error case is worth something too, probably
more than making the error case faster is worth.

In any case, the proposed scheme for providing context requires that
you know where the error is before you can identify the context.  I
considered schemes that would keep track of the last N characters or
line breaks in case one of them proved to be the one we need.  That
would add enough cycles to non-error cases to almost certainly not be
desirable.  I also considered trying to back up, but that doesn't look
promising either for arbitrary multibyte encodings.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: [RFC][PATCH] Logical Replication/BDR prototype and architecture
Next
From: Tom Lane
Date:
Subject: Re: 9.3devel branch