Re: Improvement of procArray.xmin for VACUUM
От | Tom Lane |
---|---|
Тема | Re: Improvement of procArray.xmin for VACUUM |
Дата | |
Msg-id | 25194.1174685701@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Improvement of procArray.xmin for VACUUM (Bruce Momjian <bruce@momjian.us>) |
Ответы |
Re: Improvement of procArray.xmin for VACUUM
Re: Improvement of procArray.xmin for VACUUM |
Список | pgsql-patches |
Bruce Momjian <bruce@momjian.us> writes: > I have been thinking we could improve how quickly VACUUM can expire rows > if we update procArray.xmin more frequently for non-SERIALIZABLE > transactions. > The attached patch updates procArray.xmin in this manner. This patch is incredibly broken. Didn't you understand what I said about how we don't track which snapshots are still alive? You can't advance procArray.xmin past the xmin of the oldest live snapshot in the backend, and you can't assume that there are no live snapshots at the places where this patch assumes that. (Open cursors are one obvious counterexample, but I think there are more.) To make intra-transaction advancing of xmin possible, we'd need to explicitly track all of the backend's live snapshots, probably by introducing a "snapshot cache" manager that gives out tracked refcounts as we do for some other structures like catcache entries. This might have some other advantages (I think most of the current CopySnapshot operations could be replaced by refcount increments) but it's a whole lot more complicated and invasive than what you've got here. regards, tom lane
В списке pgsql-patches по дате отправления: