Re: Range Types - typo + NULL string constructor

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: Jeff Davis <pgsql(at)j-davis(dot)com>
Cc: Alexander Korotkov <aekorotkov(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Range Types - typo + NULL string constructor
Date: 2011-10-26 06:53:46
Message-ID: 4EA7AE7A.9020505@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 25.10.2011 19:37, Jeff Davis 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.

I think we should look at the array-functions for precedent. array_in et
al cache the information in fn_extra, so that when it's called
repeatedly in one statement for the same type, the information is only
looked up once. That's good enough, it covers repeated execution in a
single query, as well as COPY and comparison calls from index searches,
for example.

> Aren't there a few other cases like this floating around the code?

Not that I know of. That said, I wouldn't be too surprised if there was.

> I know the single-xid cache is potentially vulnerable to xid wraparound
> for the same reason.

True.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2011-10-26 07:52:58 Re: Your review of pg_receivexlog/pg_basebackup
Previous Message Tom Lane 2011-10-26 03:24:33 Re: TOAST versus VACUUM, or "missing chunk number 0 for toast value" identified