On 2 Jul 2003 at 16:19, Jean-Christian Imbeault wrote:
> I just want two things from any valid solution:
>
> 1- if there is an insert and there is not row with the new insert's
> primary key then the insert is made. If there are multiple inserts one
> succeeds. i.e. No valid inserts will be 'lost'.
With postgresql, if you use transacations, no valid inserts are ever lost
unless there is a deadlock.
>
> 2- reduce the number of error messages logged as a result of
> 'collisions' between two backends trying to insert duplicate primary key
> rows.
Log of what? Postgresql will log all the errors. If you don't want to see them,
tune the logging option.
If your code is doing any checking for return value etc., check if it is a
duplicate message and discard it. That way you can minimize your application
logging.
Otherwise use select/insert behaviour referred earlier.
Besides if you are going to insert a duplicate rarely, why worry so much about
performance? And if your dulicates are bit too frequent for comfort, you might
have some more issues w.r.t database table design to look at.
Bye
Shridhar
--
And 1.1.81 is officially BugFree(tm), so if you receive any bug-reportson it,
you know they are just evil lies."(By Linus Torvalds,
Linus.Torvalds@cs.helsinki.fi)
