On 12/18/19 10:06 AM, Simon Riggs wrote:
> On Wed, 18 Dec 2019 at 17:35, Robert Haas <robertmhaas@gmail.com
> <mailto:robertmhaas@gmail.com>> wrote:
>
> On Wed, Dec 18, 2019 at 10:18 AM Simon Riggs <simon@2ndquadrant.com
> <mailto:simon@2ndquadrant.com>> wrote:
>> This was my first concern when I thought about it, but I realised
> that by taking a snapshot and then calculating xmin normally, this
> problem would go away.
>
> Why? As soon as a transaction aborts...
>
>
> So this is the same discussion as elsewhere about potentially aborted
> transactions... AFAIK, the worst that happens in that case is that
> the reading transaction will end with an ERROR, similar to a
> serializable error.
>
> And that won't happen in the use cases I've explicitly described this
> as being useful for, which is where the writing transactions have
> completed executing.
>
> I'm not claiming any useful behavior outside of those specific use
> cases; this is not some magic discovery that goes faster - the user
> has absolutely no reason to run this whatsoever unless they want to
> see uncommitted data. There is a very explicit warning advising
> against using it for anything else.
>
> Just consider this part of the recovery toolkit.
In that case, don't call it "read uncommitted". Call it some other
thing entirely. Users coming from other databases may request
"read uncommitted" isolation expecting something that works.
Currently, that gets promoted to "read committed" and works. After
your change, that simply breaks and gives them an error.
I was about to write something about security and stability problems,
but Robert and Tom did elsewhere, so I'll just echo their concerns.
Looking at the regression tests, I'm surprised read uncommitted gets
so little test coverage. There's a test in src/test/isolation but
nothing at all in src/test/regression covering this isolation level.
The one in src/test/isolation doesn't look very comprehensive. I'd
at least expect a test that verifies you don't get a syntax error
when you request READ UNCOMMITTED isolation from SQL.
--
Mark Dilger
