Re: Read Uncommitted
| От | David Steele |
|---|---|
| Тема | Re: Read Uncommitted |
| Дата | |
| Msg-id | d4a4347d-ede1-dc9b-67c1-7d653b98935f@pgmasters.net обсуждение исходный текст |
| Ответ на | Re: Read Uncommitted (Heikki Linnakangas <hlinnaka@iki.fi>) |
| Список | pgsql-hackers |
On 12/18/19 2:29 PM, Heikki Linnakangas wrote: > On 18/12/2019 20:46, Mark Dilger wrote: >> On 12/18/19 10:06 AM, Simon Riggs wrote: >>> 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 agree that if we have a user-exposed READ UNCOMMITTED isolation level, > it shouldn't be just a recovery tool. For a recovery tool, I think a > set-returning function as part of contrib/pageinspect, for example, > would be more appropriate. Then it could also try to be more defensive > against corrupt pages, and be superuser-only. +1. -- -David david@pgmasters.net
В списке pgsql-hackers по дате отправления: