Re: Read Uncommitted
От | Mark Dilger |
---|---|
Тема | Re: Read Uncommitted |
Дата | |
Msg-id | eb7bd0c9-b7ce-242b-0ce7-66923abe8ecf@gmail.com обсуждение исходный текст |
Ответ на | Re: Read Uncommitted (Simon Riggs <simon@2ndquadrant.com>) |
Ответы |
Re: Read Uncommitted
(Heikki Linnakangas <hlinnaka@iki.fi>)
Read Uncommitted regression test coverage (Mark Dilger <hornschnorter@gmail.com>) |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: