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  (Jim Nasby <decibel@decibel.org>)
Список 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 по дате отправления:

Предыдущее
От: Jim Nasby
Дата:
Сообщение: Re: Proposal: Change of pg_trigger.tg_enabled and adding
Следующее
От: Ken Johanson
Дата:
Сообщение: V3 protocol; way to return table aliases?