Re: Read Uncommitted
От | Simon Riggs |
---|---|
Тема | Re: Read Uncommitted |
Дата | |
Msg-id | CANP8+jJioT3rM1UT_QSeJbLy4wJv8doCht-kdLvZt34d-dhz2A@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Read Uncommitted (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: Read Uncommitted
Re: Read Uncommitted Re: Read Uncommitted Re: Read Uncommitted |
Список | pgsql-hackers |
On Wed, 18 Dec 2019 at 17:35, Robert Haas <robertmhaas@gmail.com> wrote:
On Wed, Dec 18, 2019 at 10:18 AM Simon Riggs <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.
В списке pgsql-hackers по дате отправления: