At 04:27 PM 1/20/2012, Florian Weimer wrote:
>* Lincoln Yeoh:
>
> >>If you use serializable transactions in PostgreSQL 9.1, you can
> >>implement such constraints in the application without additional
> >>locking. However, with concurrent writes and without an index, the rate
> >>of detected serialization violations and resulting transactions aborts
> >>will be high.
> >
> > Would writing application-side code to handle those transaction aborts
> > in 9.1 be much easier than writing code to handle transaction
> > aborts/DB exceptions due to unique constraint violations? These
> > transaction aborts have to be handled differently (e.g. retried for X
> > seconds/Y tries) from other sort of transaction aborts (not retried).
>
>There's a separate error code, so it's easier to deal with in theory.
Is there a simple way to get postgresql to retry a transaction, or
does the application have to actually reissue all the necessary
statements again?
I'd personally prefer to use locking and selects to avoid transaction
aborts whether due to unique constraint violations or due to
serialization violations.
But I'm lazy ;).
Regards,
Link.
