Conversation

Fascinating disconnect I’ve seen on this one: - academic researchers: SERIALIZABLE isn’t the default? But everyone enables it first thing, right? - database users: SERIALIZABLE exists?

Quote Tweet

Brent Ozar

@BrentO

Sep 13

"Why isolation level serializable is not the default?" reddit.com/r/Database/com Oh my.

115

Dan Ports

@danrkports

Sep 14

note: not exaggerating on this one. [postgresql.org, ~2011, around the time our work on Serializable Snapshot Isolation became available]

Survey Results
The current results of our Do you use SERIALIZABLE transaction mode? survey are:

Answer Responses Percentage

Yes, we depend on it for production code 29 15.026%
Yes, but only for a few non-critical things 11 5.699%
I've been messing with it in development (only) 17 8.808%
No, I never considered it 39 20.207%
No, I found SERIALIZABLE too unintuitive/undependable 10 5.181%
What's SERIALIZABLE? 81 41.969%

Total 193

read image description

ALT

Replying to

Even this seems biased - it's got to be more than 41%. (Please don't interpret this as a slight against SSI. SSI is a very important feature IMV.)

Replying to

and

I wish somebody would spend a while making postgres' SSI implementation more scalable. Right now the locking is, uh, coarse grained. I don't think it'd even be that hard to do substantially better than we do right now.

Replying to

and

That's almost certainly true, but I maintain that the main problem by far is the developer experience. And I don't know what can be done about that.

Replying to

and

My answer: fix the remaining obstacles to auto-retry, and encourage users to use decent transaction management libraries that do that.

Replying to

and

Hmm. Maybe having good/better framework-level support would actually move the needle. It at least addresses the root problem, which is a start.

2:18 AM · Sep 16, 2022Twitter Web App

Replying to

and

See my SSI ideas list here for the two problems I am aware of to be solved so as not to confuse auto-retrying client libraries (two kinds of constraint violations): wiki.postgresql.org/wiki/Serializa

Replying to

I'm aware of one other problem: the existence of a 2PC can make retrying fail forever (until the 2PC completes). Got anything else that stands in the way of auto-retry?