Re: Read Uncommitted
От | Robert Haas |
---|---|
Тема | Re: Read Uncommitted |
Дата | |
Msg-id | CA+TgmoabdBCUL-kujCnLZ1kGmLny2aKgHXaQHZZm42VD_GYA7g@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Read Uncommitted (Simon Riggs <simon@2ndquadrant.com>) |
Ответы |
Re: Read Uncommitted
|
Список | pgsql-hackers |
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, the TOAST rows can be vacuumed away, but the READ UNCOMMITTED transaction might've already seen the main tuple. This is not even a particularly tight race, necessarily, since for example the table might be scanned, feeding tuples into a tuplesort, and then the detoating might happen further up in the query tree after the sort has completed. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: