Re: Read Uncommitted

On Fri, 20 Dec 2019 at 12:18, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Craig Ringer <craig(at)2ndquadrant(dot)com> writes:
> > My understanding from reading the above is that Simon didn't propose to
> > make aborted txns visible, only in-progress uncommitted txns.
>
> Yeah, but an "in-progress uncommitted txn" can become an "aborted txn"
> at any moment, and there's no interlock that would prevent its generated
> data from being removed out from under you at any moment after that.
> So there's a race condition, and as Robert observed, the window isn't
> necessarily small.
>

Absolutely. Many of the same issues arise in the work on logical decoding
of in-progress xacts for optimistic logical decoding.

Unless such an interlock is added (with all the problems that entails,
again per the in-progress logical decoding thread) that limits this to:

* running in recovery when stopped at a recovery target; or
* peeking at the contents of individual prepared xacts that we can prevent
someone else concurrently aborting/committing

That'd actually cover the only things I'd personally actually want a
feature like this for anyway.

In any case, Simon's yanked the proposal. I'd like to have some way to peek
at the contents of individual uncommited xacts, but it's clearly not going
to be anything called READ UNCOMMITTED that applies to all uncommitted
xacts at once...

> > I think the suggestions for a SRF based approach might make sense.
>
> Yeah, I'd rather do it that way than via a transaction isolation
> level. The isolation-level approach seems like people will expect
> stronger semantics than we could actually provide.
>

Yeah. Definitely not an isolation level.

I'll be interesting to see if this sparks any more narrowly scoped and
targeted ideas, anyway. Thanks for taking the time to think about it.

--
Craig Ringer http://www.2ndQuadrant.com/
2ndQuadrant - PostgreSQL Solutions for the Enterprise