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 behavior
Ron Mayer rm...@cheapcomplexdevices.com 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
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 then
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
such a
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 past.
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
Josh Berkus j...@agliodbs.com 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
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
Josh Berkus j...@agliodbs.com 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
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
Tom Lane t...@sss.pgh.pa.us 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
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
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 that
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
some
On Mon, Jan 10, 2011 at 1:17 PM, Josh Berkus j...@agliodbs.com 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
Josh Berkus j...@agliodbs.com 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.
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 clear
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
2011/1/11 Robert Haas robertmh...@gmail.com:
On Mon, Jan 10, 2011 at 1:17 PM, Josh Berkus j...@agliodbs.com 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
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
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
Kevin Grittner kevin.gritt...@wicourts.gov 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
On Sun, Jan 9, 2011 at 7:47 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Kevin Grittner kevin.gritt...@wicourts.gov 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,
23 matches
Mail list logo
