Re: Range Types - typo + NULL string constructor
От | Robert Haas |
---|---|
Тема | Re: Range Types - typo + NULL string constructor |
Дата | |
Msg-id | CA+Tgmoai8sAFjmu3jG4ff58vpSsO2SSX=fJs4NGgHpBTK0y=bA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Range Types - typo + NULL string constructor (Jeff Davis <pgsql@j-davis.com>) |
Ответы |
Re: Range Types - typo + NULL string constructor
Re: Range Types - typo + NULL string constructor |
Список | pgsql-hackers |
On Tue, Oct 25, 2011 at 12:37 PM, Jeff Davis <pgsql@j-davis.com> wrote: > On Mon, 2011-10-24 at 13:15 +0300, Heikki Linnakangas wrote: >> Hmm, I don't think that's safe. After Oid wraparound, a range type oid >> might get reused for some other range type, and the cache would return >> stale values. Extremely unlikely to happen by accident, but could be >> exploited by an attacker. > > Any ideas on how to remedy that? I don't have another plan for making it > perform well. Plugging it into the cache invalidation mechanism seems > like overkill, but I suppose that would solve the problem. > > Aren't there a few other cases like this floating around the code? I > know the single-xid cache is potentially vulnerable to xid wraparound > for the same reason. I believe that we're in trouble with XIDs as soon as you have two active XIDs that are separated by a billion, because then you could have a situation where some people think a given XID is in the future and others think it's in the past. I have been wondering if we should have some sort of active guard against that scenario; I don't think we do at present. But OID wraparound is not the same as XID wraparound. It's far more common, I think, for a single transaction to use lots of OIDs than it is for it to use lots of XIDs (i.e. have many subtransactions). -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: