Kevin Grittner writes ("Re: [HACKERS] [OSSTEST PATCH 0/1] PostgreSQL db: Retry
on constraint violation [and 2 more messages] [and 1 more messages]"):
> On Thu, Dec 15, 2016 at 6:09 AM, Ian Jackson
> wrote:
> > [...] Are there other reasons,
> > besides previou
Kevin Grittner writes ("Re: [HACKERS] [OSSTEST PATCH 0/1] PostgreSQL db: Retry
on constraint violation [and 2 more messages] [and 1 more messages]"):
> As Robert pointed out, a read-only transaction cannot normally be
> aborted by a serialization failure on COMMIT. Under exceptional
> conditions,
Kevin Grittner writes ("Re: [HACKERS] [OSSTEST PATCH 0/1] PostgreSQL db: Retry
on constraint violation [and 2 more messages] [and 1 more messages]"):
> On Wed, Dec 14, 2016 at 10:20 AM, Ian Jackson
> wrote:
>
> > Let me try to summarise my understanding of what the
Robert Haas writes ("Re: [HACKERS] [OSSTEST PATCH 0/1] PostgreSQL db: Retry on
constraint violation [and 2 more messages]"):
> On Wed, Dec 14, 2016 at 9:26 AM, Kevin Grittner wrote:
> > considered. Essentially, the position Ian has been taking is that
> > PostgreSQL should provide the guarantee
he pgsql docs) ought to be a stronger version, which
covers even non-committed transactions.
> [Ian Jackson:]
> > But I have just demonstrated a completely general technique which can
> > be used to convert any "spurious" constraint failure into a nonsense
> > transactio
Kevin Grittner writes ("Re: [HACKERS] [OSSTEST PATCH 0/1] PostgreSQL db: Retry
on constraint violation [and 2 more messages]"):
> On Tue, Dec 13, 2016 at 5:30 AM, Ian Jackson
> wrote:
> > Are all of these cases fixed by fcff8a57519847 "Detect SSI conflicts
>
Thanks to everyone for your attention.
Kevin Grittner writes ("Re: [HACKERS] [OSSTEST PATCH 0/1] PostgreSQL db: Retry
on constraint violation"):
> On Mon, Dec 12, 2016 at 8:45 AM, Ian Jackson
> wrote:
> > AIUI the documented behavour is that "every set of suc
Kevin Grittner writes ("Re: [HACKERS] [OSSTEST PATCH 0/1] PostgreSQL db: Retry
on constraint violation"):
> If I recall correctly, the constraints for which there can be
> errors appearing due to concurrent transactions are primary key,
> unique, and foreign key constraints. I don't remember seei
This is unfortunate but appears to be necessary.
Signed-off-by: Ian Jackson
CC: pgsql-hackers@postgresql.org
---
Osstest/JobDB/Executive.pm | 45 -
tcl/JobDB-Executive.tcl| 6 --
2 files changed, 48 insertions(+), 3 deletions(-)
diff --git a
Hi. This message is going to xen-devel (because that's where the
osstest project is) and to pgsql-hackers (because I hope they may be
able to advise about the scope of the PostgreSQL SERIALIZABLE
constraint problem).
In summary: PostgreSQL only provides transaction serialisability for
successful
10 matches
Mail list logo
