From: | Christopher BROWN <brown(at)reflexe(dot)fr> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-jdbc <pgsql-jdbc(at)postgresql(dot)org> |
Subject: | Re: Handling transaction failure due to concurrency errors |
Date: | 2018-03-02 15:27:17 |
Message-ID: | CAHL_zcN5n+EzDT8wfdbbgU=0yqThGgDEh94LBC+a9yjQvW=Cow@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-jdbc |
Tom,
That's what I was looking for, so thanks, I'll give it a go.
Best regards,
Christopher
On 2 March 2018 at 16:21, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Christopher BROWN <brown(at)reflexe(dot)fr> writes:
> > Thanks for the quick reply. OK for the explanation, and I don't mind
> > implementing the retry logic for this case... I just don't know how to
> > detect when my code encounters this case (as opposed to other cases that
> > can arise, such as unresolved foreign keys when importing data; I don't
> > want to get into an infinite retry loop because it will never work in
> these
> > other cases).
>
> Yes, you should only retry in this way for the specific case of a
> serialization failure (SQLSTATE 40001).
>
> regards, tom lane
>
From | Date | Subject | |
---|---|---|---|
Next Message | Dave Cramer | 2018-03-02 21:05:13 | Re: MyBatis Batch Update Leads to PSQLException "Too many update results were returned" |
Previous Message | Tom Lane | 2018-03-02 15:21:18 | Re: Handling transaction failure due to concurrency errors |