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  (Robert Haas <robertmhaas@gmail.com>)
Re: Read Uncommitted  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Read Uncommitted  (Mark Dilger <hornschnorter@gmail.com>)
Re: Read Uncommitted  (Andres Freund <andres@anarazel.de>)
Список 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.

--
Simon Riggs                http://www.2ndQuadrant.com/
PostgreSQL Solutions for the Enterprise

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Ranier Vilela
Дата:
Сообщение: RE: Windows port minor fixes
Следующее
От: Fabrízio de Royes Mello
Дата:
Сообщение: Re: Restore backup file "with oids"