From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Mikko Vierula <mikko(dot)vierula(at)elektroniikkatyo(dot)fi> |
Cc: | pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: Serializable access giving wrong error messages? |
Date: | 2001-12-27 14:49:50 |
Message-ID: | 24358.1009464590@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Mikko Vierula <mikko(dot)vierula(at)elektroniikkatyo(dot)fi> writes:
> But all
> those errors really are because of serialization problems. So shouldn't
> I be receiving a error stating that?
I disagree, because I don't think it's reasonable to expect the system
to make that deduction. I prefer a specific error message telling you
what's actually wrong ("duplicate key") to a vague error message that
might in fact be incorrect (leaping to a "can't serialize access"
conclusion).
In the example you give, the reason that you as an intelligent human can
classify the error as a serialization problem is that earlier in the
transaction you searched for the key and didn't find it. Had you not
done that, you could not argue that "duplicate key" is the wrong message.
Now, is the system supposed to remember that there was such a search,
and do the logical deductions needed to correlate the previous WHERE
clause to the immediate cause of failure? Sorry, I don't think so.
We'd have to remember the conditions and outputs of every SELECT
throughout every transaction in order to adjust this error message.
That's an unrealistic amount of overhead for a mighty small return.
I counsel tweaking your program logic so that a "duplicate key" error
at this point is treated as a retryable failure.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Scott Royston | 2001-12-27 20:37:14 | Implicit cast of literal in SQL statements |
Previous Message | Mikko Vierula | 2001-12-27 09:30:35 | Re: Serializable access giving wrong error messages? |