On Thu, May 3, 2012 at 11:46 AM, Kevin Grittner <kevin.gritt...@wicourts.gov> wrote: > Alvaro Herrera <alvhe...@commandprompt.com> wrote: >> Excerpts from Magnus Hagander's message: >>> Tom Lane <t...@sss.pgh.pa.us> wrote: >>>> In the context of yesterday's discussions, I wonder whether a >>>> filter by SQLSTATE would be appropriate. >>> >>> I'm worried it's not really granular enough. >> >> Yeah. > > Just to be sure we're not inventing a problem here, can someone > produce an example of a situation where it would not be granular > enough (assuming we correct bad SQLSTATE choices where they exist)? > > I count 232 distinct SQLSTATE values (139 standard values and 93 > PostgreSQL-specific values), and we can create more if we > want them; although I would recommend against doing that to get > finer resolution on a standard SQLSTATE value. A standard value > which is too coarse would be the strongest argument for adding some > other mechanism, IMO. If we do, I would be inclined toward > something to identify distinct conditions within a SQLSTATE, rather > than some overarching independent mechanism.
Well, nearby Tom and I discussed demoting the message to DEBUG1 when no transaction is in progress. Presumably the two messages would share the same SQL state, unless we're going to create separate SQL states for connection-closed-not-in-a-txn and connection-closed-in-a-txn; and yet I think there's a very decent argument that you're much more likely to care about the latter than the former. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
