On Tue, Oct 25, 2011 at 12:37 PM, Jeff Davis <pg...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
