Re: GetOldestXmin going backwards is dangerous after all
От | Simon Riggs |
---|---|
Тема | Re: GetOldestXmin going backwards is dangerous after all |
Дата | |
Msg-id | CA+U5nM+vZ+gcu-8+8Ouy9AY_CMTrMneUVFmaT69C_zM2FMDEUg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: GetOldestXmin going backwards is dangerous after all (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On 2 February 2013 00:24, Tom Lane <tgl@sss.pgh.pa.us> wrote: > * if allDbs is FALSE and there are no transactions running in the current > * database, GetOldestXmin() returns latestCompletedXid. If a transaction > * begins after that, its xmin will include in-progress transactions in other > * databases that started earlier, so another call will return a lower value. > > The reason this is a problem is that GetOldestXmin ignores XIDs of > processes that are connected to other DBs. It now seems to me that this > is a flat-out bug. It can ignore their xmins, but it should include > their XIDs, because the point of considering those XIDs is that they may > contribute to the xmins of snapshots computed in the future by processes > in our own DB. And snapshots never exclude any XIDs on the basis of > which DB they're in. (They can't really, since we can't know when the > snap is taken whether it might be used to examine shared catalogs.) Agree thats a bug. -- Simon Riggs http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: