Re: conditional insert

At 04:04 AM 9/8/2011, Andrew Sullivan wrote:
>On Wed, Sep 07, 2011 at 02:51:32PM -0500, Merlin Moncure wrote:
> >
> > @andrew s: going SERIALIZABLE doesn't help if you trying to eliminate
> > cases that would push you into retrying the transaction.
>
>Well, no, of course.  But why not catch the failure and retry?  I
>guess I just don't get the problem, since I hear people say this all
>the time.  (I mean, I've also seen places where 'upsert' would be
>cool, but it doesn't seem trivial to do in a general way and you can
>do this with catch-serialization-error-and-retry, I think?)

Doesn't catching the failure and retrying mean writing more code?

Need extra code:
1) to handle the savepoint.
2) to correctly distinguish between "retryable" errors and
"nonretryable" errors.
3) to retry transactions.

More code to debug, test, document and support :).

In contrast, the "lock table, insert if row does not exist, update if
it exists" and rollback everything if "stuff happens" seems simpler
to do correctly.

I personally prefer to leave as much code writing to others (e.g.
those writing Postgresql, programming languages and libraries),
because I assume they are much better at writing code than I am. Plus
I usually don't have to document and support their code ;).

Regards,
Link.