Re: Proposal: Snapshot cloning
От | Tom Lane |
---|---|
Тема | Re: Proposal: Snapshot cloning |
Дата | |
Msg-id | 24805.1170131332@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Proposal: Snapshot cloning (Jim Nasby <decibel@decibel.org>) |
Ответы |
Re: Proposal: Snapshot cloning
|
Список | pgsql-hackers |
Jim Nasby <decibel@decibel.org> writes: > On Jan 26, 2007, at 4:48 PM, Tom Lane wrote: >> I don't actually see that it buys you a darn thing ... you still won't >> be able to delete dead updated tuples because of the possibility of >> the LRT deciding to chase ctid chains up from the tuples it can see. > Well, Simon was talking about a serialized LRT, which ISTM shouldn't > be hunting down ctid chains past the point it serialized at. How you figure that? If the LRT wants to update a tuple, it's got to chase the ctid chain to see whether the head update committed or not. It's not an error for a serializable transaction to update a tuple that was tentatively updated by a transaction that rolled back. > Even if that's not the case, there is also the possibility if a LRT > publishing information about what tables it will hit. I think we already bought 99% of the possible win there by fixing vacuum. Most ordinary transactions aren't going to be able to predict which other tables the user might try to touch. regards, tom lane
В списке pgsql-hackers по дате отправления: