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.
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
