Kevin,
I think you overestimate what we can meaninfully put in a tiny
radio-button survey.
I'm only trying to get a straw poll idea of whether we have lots of
people using SERIALIZABLE mode *at all*, or (as I suspect) almost none.
If we get < 5% or respondees saying "we use it in production" the
Ron Mayer wrote:
> That Survey's missing one important distinction for that
> discussion.
>
> Do you take the the current survey answer
>
>"Yes, we depend on it for production code"
>
> to imply
>
>"Yes, we depend on actual real SERIALIZABLE transactions in
> production and will
Josh Berkus wrote:
>> Mainly, that it's not clear we need it. Nobody's pointed to a concrete
>> failure mechanism that makes it necessary for an existing app to run
>> under fake-SERIALIZABLE mode.
>
> I think it's quite possible that you're right, and nobody depends on
> current SERIALIZABLE beh
On Jan10, 2011, at 20:29 , Josh Berkus wrote:
> The only reason I'm ambivalent about
> this is I'm unsure that there are more than a handful of people using
> SERIALIZABLE in production applications, precisely because it's been so
> unintuitive in the past.
I've used it quite extensively in the pa
On Jan10, 2011, at 23:56 , Kevin Grittner wrote:
>> The proposed GUC would suppress the monitoring in SERIALIZABLE
>> mode and avoid the new serialization failures, thereby providing
>> legacy behavior -- anomalies and all.
>
> After posting that I realized that there's no technical reason that
>
2011/1/11 Robert Haas :
> On Mon, Jan 10, 2011 at 1:17 PM, Josh Berkus wrote:
>> I'm going to disagree here. For a large, sprawling, legacy application
>> changing SERIALIZABLE to REPEATABLE READ in every place in the code
>> which might call it can be prohibitively difficult.
>
> What makes you t
> Mainly, that it's not clear we need it. Nobody's pointed to a concrete
> failure mechanism that makes it necessary for an existing app to run
> under fake-SERIALIZABLE mode.
I think it's quite possible that you're right, and nobody depends on
current SERIALIZABLE behavior because it's undepend
Josh Berkus wrote:
>> Really, the biggest risk of such a GUC is the confusion factor
>> when supporting people.
> How is this different from our other backwards-compatibility GUCs?
I thought Tom might be concerned about such a GUC destabilizing
things in other ways. I just wanted to make cl
Josh Berkus writes:
> How is this different from our other backwards-compatibility GUCs?
Mainly, that it's not clear we need it. Nobody's pointed to a concrete
failure mechanism that makes it necessary for an existing app to run
under fake-SERIALIZABLE mode.
regards, tom
On Mon, Jan 10, 2011 at 1:17 PM, Josh Berkus wrote:
> I'm going to disagree here. For a large, sprawling, legacy application
> changing SERIALIZABLE to REPEATABLE READ in every place in the code
> which might call it can be prohibitively difficult.
What makes you think that would be necessary? T
> If we must have a GUC, perhaps we could publish a sunset one release in
> the future.
I was thinking default to false/off in 9.1, and disappear in 9.3.
> Really, the biggest risk of such a GUC is the confusion factor when
> supporting people. If we're told that the transactions involved in
>
On Mon, 2011-01-10 at 11:29 -0800, Josh Berkus wrote:
> On 1/10/11 10:47 AM, Kevin Grittner wrote:
> > If they're not using SERIALIZABLE, this patch will have no impact on
> > them at all. If they are using SELECT FOR UPDATE *with*
> > SERIALIZABLE, everything will function exactly as it is except
I wrote:
> The proposed GUC would suppress the monitoring in SERIALIZABLE
> mode and avoid the new serialization failures, thereby providing
> legacy behavior -- anomalies and all.
After posting that I realized that there's no technical reason that
such a GUC couldn't be set within each session
Tom Lane wrote:
> I think we've learned over the years that GUCs that significantly
> change semantics can be foot-guns. I'm not sure exactly how
> dangerous this one would be
I didn't respond to this at first because the idea seemed DOA, but
with Josh's concerns I guess I should answer this
On 1/10/11 10:47 AM, Kevin Grittner wrote:
> If they're not using SERIALIZABLE, this patch will have no impact on
> them at all. If they are using SELECT FOR UPDATE *with*
> SERIALIZABLE, everything will function exactly as it is except that
> there may be some serialization failures which they we
Josh Berkus wrote:
> my clients have tended to use SELECT FOR UPDATE instead of
> SERIALIZABLE.
If they're not using SERIALIZABLE, this patch will have no impact on
them at all. If they are using SELECT FOR UPDATE *with*
SERIALIZABLE, everything will function exactly as it is except that
ther
On 1/10/11 10:28 AM, Kevin Grittner wrote:
> The techniques we use in our shop wouldn't interact badly with SSI,
> and I'm having trouble picturing what would. Sure, some of these
> techniques would no longer be needed, and would only add overhead if
> SSI was there.
Yeah? Well, you have more ex
Josh Berkus wrote:
> many such applications would be written with workarounds for
> broken serializable behavior, workarounds which would behave
> unpredictably after an upgrade.
Can you elaborate?
The techniques we use in our shop wouldn't interact badly with SSI,
and I'm having trouble pic
On 1/9/11 5:27 PM, Robert Haas wrote:
> I agree. I think we should assume that existing code which asks for
> serializable behavior wants serializable behavior, not broken
> serializable behavior. There certainly could be cases where the
> opposite is true (the code wants, specifically, our tradi
On Sun, Jan 9, 2011 at 7:47 PM, Tom Lane wrote:
> "Kevin Grittner" writes:
>> If the SSI patch were to be accepted as is, REPEATABLE READ would
>> continue to provide the exact same snapshot isolation behavior which
>> both it and SERIALIZABLE do through 9.0, and SERIALIZABLE would
>> always use
"Kevin Grittner" writes:
> If the SSI patch were to be accepted as is, REPEATABLE READ would
> continue to provide the exact same snapshot isolation behavior which
> both it and SERIALIZABLE do through 9.0, and SERIALIZABLE would
> always use SSI on top of the snapshot isolation to prevent
> seria
On Sun, Jan 09, 2011 at 12:07:49PM -0600, Kevin Grittner wrote:
> There's an issue where we don't seem to have consensus yet, so I
> figured I'd bounce it off the list.
>
> If the SSI patch were to be accepted as is, REPEATABLE READ would
> continue to provide the exact same snapshot isolation be
There's an issue where we don't seem to have consensus yet, so I
figured I'd bounce it off the list.
If the SSI patch were to be accepted as is, REPEATABLE READ would
continue to provide the exact same snapshot isolation behavior which
both it and SERIALIZABLE do through 9.0, and SERIALIZABLE wou
23 matches
Mail list logo
