Re: Read Uncommitted
| От | Craig Ringer |
|---|---|
| Тема | Re: Read Uncommitted |
| Дата | |
| Msg-id | CAMsr+YGxwKFWZN-kkGhJt8gGjykwbEuTq-ByuoJ0D6S3dPXFcg@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Read Uncommitted (Andres Freund <andres@anarazel.de>) |
| Ответы |
Re: Read Uncommitted
(Tom Lane <tgl@sss.pgh.pa.us>)
|
| Список | pgsql-hackers |
On Thu, 19 Dec 2019 at 23:36, Andres Freund <andres@anarazel.de> wrote:
Hi,
> On the patch as proposed this wouldn't be possible because a toast row
> can't be vacuumed and then reused while holding back xmin, at least as I
> understand it.
Vacuum and pruning remove rows where xmin didn't commit, without testing
against the horizon. Which makes sense, because normally there's so far
no snapshot including them. Unless we were to weaken that logic -
which'd have bloat impacts - a snapshot wouldn't guarantee anything
about the non-removal of such tuples, unless I am missing something.
My understanding from reading the above is that Simon didn't propose to make aborted txns visible, only in-progress uncommitted txns.
Vacuum only removes such rows if the xact is (a) explicitly aborted in clog or (b) provably not still running. It checks RecentXmin and the running xids arrays to handle xacts that went away after a crash. Per TransactionIdIsInProgress() as used by HeapTupleSatisfiesVacuum(). I see that it's not *quite* as simple as using the RecentXmin threhold, as xacts newer than RecentXmin may also be seen as not in-progress if they're absent in the shmem xact arrays and there's no overflow.
But that's OK so long as the only xacts that some sort of read-uncommitted feature allows to become visible are ones that satisfy TransactionIdIsInProgress(); they cannot have been vacuumed.
The bigger issue, and the one that IMO makes it impractical to spell this as "READ UNCOMMITTED", is that an uncommitted txn might've changed the catalogs so there is no one snapshot that is valid for interpreting all possible tuples. It'd have to see only txns that have no catalog changes, or be narrowed to see just *one specific txn* that had catalog changes. That makes it iffy to spell it as "READ UNCOMMITTED" since we can't actually make all uncommitted txns visible at once.
I think the suggestions for a SRF based approach might make sense. Perhaps a few functions:
* a function to list all in-progress xids
* a function to list in-progress xids with/without catalog changes (if possible, unsure if we know that until the commit record is written)
* a function (or procedure?) to execute a read-only SELECT or WITH query within a faked-up snapshot for some in-progress xact and return a SETOF RECORD with results. If the txn has catalog changes this would probably have to coalesce each result field with non-builtin data types to text, or do some fancy validation to compare the definition in the txn snapshot with the latest normal snapshot used by the calling session. Ideally this function could take an array of xids and would query with them all visible unless there were catalog changes in any of them, then it'd ERROR.
* a function to generate the SQL text for an alias clause that maps the RECORD returned by the above function, so you can semi-conveniently query it. (I don't think we have a way for a C callable function to supply a dynamic resultset type at plan-time to avoid the need for this, do we? Perhaps if we use a procedure not a function?)
В списке pgsql-hackers по дате отправления: