Re: the case for machine-readable error fields

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: <pgsql-hackers(at)postgresql(dot)org>,"Sam Mason" <sam(at)samason(dot)me(dot)uk>
Subject: Re: the case for machine-readable error fields
Date: 2009-08-05 18:46:00
Message-ID: 4A798D180200002500029454@gw.wicourts.gov
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Sam Mason <sam(at)samason(dot)me(dot)uk> wrote:

> Still doesn't really describe the
> engineering rational behind it though.

Well, the distinctions in many cases would be mostly of interest to a
DBA managing a large shop who was trying to characterize the reasons
for query failure. Some codes, however, are particularly valuable.

At the low end, classes '00' (information), '01' (warning), and '02'
(no rows affected) can be used for useful, if mundane, purposes. A
really interesting one is '40001' -- which indicates that your
transaction was rolled back because of conflicts with concurrent
transactions. Our framework, for example, resubmits transactions
which fail with this SQL state; the user, and indeed the application
code, never have any indication that the transaction was rolled back
and restarted -- it appears just the same as a delay caused by
blocking. (Our logs, of course, track these, so we can look to reduce
conflicts.)

> I still stand by my assertion that the constraint name is sufficient
> for the original purpose.

After thinking about that some more, I think I'm sold.

-Kevin

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2009-08-05 18:46:26 Re: [COMMITTERS] pgsql: Use DocBook XSL stylesheets for man page building This switches
Previous Message Petr Jelinek 2009-08-05 18:35:54 Re: GRANT ON ALL IN schema