Re: Proposal: Snapshot cloning
От | Jim Nasby |
---|---|
Тема | Re: Proposal: Snapshot cloning |
Дата | |
Msg-id | E029C51F-314C-41C8-89C3-3F1E34313F93@decibel.org обсуждение исходный текст |
Ответ на | Re: Proposal: Snapshot cloning (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Proposal: Snapshot cloning
|
Список | pgsql-hackers |
On Jan 26, 2007, at 4:48 PM, Tom Lane wrote: > "Simon Riggs" <simon@2ndquadrant.com> writes: >> You got me. My description was too loose, but you also got the rough >> picture. We'll save the detail for another day, but we all know its a >> bridge we will have to cross one day, soon. I wasn't meaning to raise >> this specific discussion now, just to say that publishing >> snapshots for >> known LRTs is one way by which we can solve the LRT/VACUUMing issue. > > 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. You > also seem to be assuming that a transaction can have only one > snapshot, > which is not something we can enforce in enough cases to make it a > very > useful restriction. Well, Simon was talking about a serialized LRT, which ISTM shouldn't be hunting down ctid chains past the point it serialized at. Even if that's not the case, there is also the possibility if a LRT publishing information about what tables it will hit. Any tables not being touched by a LRT could be vacuumed past the global minxid. It would be up to the user to do that in many cases, but that's likely to be well worth it if you have LRTs that are only hitting a few tables yet you have other tables that really, really need to stay vacuumed. Believe me, that is a very common use case in the real world (think queue table, or web session table). -- Jim Nasby jim@nasby.net EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
В списке pgsql-hackers по дате отправления: