Simon Riggs writes:
> On Thu, 24 Mar 2022 at 16:29, Tom Lane wrote:
>> How about the attached? (Only the third new para is different.)
> It's much better, thanks.
Pushed then.
regards, tom lane
On Thu, 24 Mar 2022 at 16:29, Tom Lane wrote:
>
> Simon Riggs writes:
> > On Thu, 24 Mar 2022 at 14:56, Tom Lane wrote:
> >> Um, what's that got to do with it? The example in
> >> read-write-unique-4.spec involves only a single pkey constraint.
>
> > Yes, but as you explained, its not actually
Simon Riggs writes:
> On Thu, 24 Mar 2022 at 14:56, Tom Lane wrote:
>> Um, what's that got to do with it? The example in
>> read-write-unique-4.spec involves only a single pkey constraint.
> Yes, but as you explained, its not actually a serializable case, it
> just looks a bit like one.
> That
On Thu, 24 Mar 2022 at 14:56, Tom Lane wrote:
>
> Simon Riggs writes:
> > OK, I see what you mean. There are 2 types of transaction, one that
> > reads inside the transaction, one that decides what value to use some
> > other way.
>
> > So now we have 2 cases, both of which generate uniqueness vi
Simon Riggs writes:
> OK, I see what you mean. There are 2 types of transaction, one that
> reads inside the transaction, one that decides what value to use some
> other way.
> So now we have 2 cases, both of which generate uniqueness violations,
> but only one of which might succeed if retried.
On Thu, 24 Mar 2022 at 14:05, Tom Lane wrote:
>
> Thomas Munro writes:
> > On Thu, Mar 24, 2022 at 11:44 PM Simon Riggs
> > wrote:
> >> The unique violation thing is worryingly general. Do we know enough to
> >> say that this is thought to occur only with a) multiple unique
> >> constraints, b)
Thomas Munro writes:
> On Thu, Mar 24, 2022 at 11:44 PM Simon Riggs
> wrote:
>> The unique violation thing is worryingly general. Do we know enough to
>> say that this is thought to occur only with a) multiple unique
>> constraints, b) exclusion constraints?
> I'm aware of 3 cases. The two you
On Thu, 24 Mar 2022 at 11:01, Thomas Munro wrote:
>
> On Thu, Mar 24, 2022 at 11:44 PM Simon Riggs
> wrote:
> > The unique violation thing is worryingly general. Do we know enough to
> > say that this is thought to occur only with a) multiple unique
> > constraints, b) exclusion constraints?
>
>
On Thu, Mar 24, 2022 at 11:44 PM Simon Riggs
wrote:
> The unique violation thing is worryingly general. Do we know enough to
> say that this is thought to occur only with a) multiple unique
> constraints, b) exclusion constraints?
I'm aware of 3 cases. The two you mentioned, which I think we can
On Wed, 23 Mar 2022 at 19:50, Tom Lane wrote:
>
> Simon Riggs writes:
> > I've tried to sum up the various points from everybody into this doc
> > patch. Thanks all for replies.
>
> This seemed rather badly in need of copy-editing. How do you
> like the attached text?
Seems clear and does the j
Simon Riggs writes:
> I've tried to sum up the various points from everybody into this doc
> patch. Thanks all for replies.
This seemed rather badly in need of copy-editing. How do you
like the attached text?
regards, tom lane
diff --git a/doc/src/sgml/mvcc.sgml b/doc/s
On Thu, 16 Dec 2021 at 06:05, Greg Stark wrote:
> So a lot of users are probably looking at something like "BEGIN;
> SELECT create_customer_order(); COMMIT" and wondering why the
> server can't handle automatically retrying the query if they get an
> isolation failure.
I agree with you that
On Wed, 29 Dec 2021 at 03:30, Thomas Munro wrote:
>
> On Fri, Dec 10, 2021 at 1:43 AM Simon Riggs
> wrote:
> > "Applications using this level must be prepared to retry transactions
> > due to serialization failures."
> > ...
> > "When an application receives this error message, it should abort th
On Fri, Dec 10, 2021 at 1:43 AM Simon Riggs
wrote:
> "Applications using this level must be prepared to retry transactions
> due to serialization failures."
> ...
> "When an application receives this error message, it should abort the
> current transaction and retry the whole transaction from the
Fwiw I think the real problem with automatic retries is that the SQL
interface doesn't lend itself to it because the server never really
knows if the command is going to be followed by a commit or more
commands.
I actually think if that problem were tackled it would very likely be
a highly appreci
On Thu, Dec 9, 2021 at 7:43 AM Simon Riggs wrote:
> I had a conversation with Kevin Grittner about retry some years back
> and it seemed clear that the application should re-execute application
> logic from the beginning, rather than just slavishly re-execute the
> same SQL. But that is not docume
"Applications using this level must be prepared to retry transactions
due to serialization failures."
...
"When an application receives this error message, it should abort the
current transaction and retry the whole transaction from the
beginning."
I note that the specific error codes this applies
17 matches
Mail list logo
