Skip site navigation (1) Skip section navigation (2)

Re: Serializable access giving wrong error messages?

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 (view raw or flat)
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

In response to

Responses

pgsql-bugs by date

Next:From: Scott RoystonDate: 2001-12-27 20:37:14
Subject: Implicit cast of literal in SQL statements
Previous:From: Mikko VierulaDate: 2001-12-27 09:30:35
Subject: Re: Serializable access giving wrong error messages?

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group