From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Ryan VanderBijl <rvbijl-pgsql(at)vanderbijlfamily(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: serialization errors |
Date: | 2003-01-28 17:47:20 |
Message-ID: | 20701.1043776040@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Ryan VanderBijl <rvbijl-pgsql(at)vanderbijlfamily(dot)com> writes:
> There are many reasons that the INSERT statement could fail (e.g. syntax,
> database connection dropped, conflicting concurrent update, unique constraint).
An INSERT statement can *never* fail because of a concurrent conflicting
update, because it isn't an update. Any INSERT is, logically speaking,
creating a unique new entity (row) in the database; there is no conflict
against other insertions, unless by way of violation of a unique constraint.
> If I receive the legal error "duplicate key" error, how am I supposed to
> detect if that error is due to a concurrent update, or because of some
> other error elsewhere?
What difference does it make if the other guy got there ten microseconds
or ten years earlier? He inserted before you did. Whether it's
"concurrent" or not shouldn't matter that I can see. Perhaps more to
the point, there is no reason to expect that a duplicate-key failure
will succeed if you retry the same insertion.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tilo Schwarz | 2003-01-28 17:47:57 | Q: Rename constraint |
Previous Message | Vivek Khera | 2003-01-28 17:43:27 | Re: Using RSYNC for replication? |