Re: No sanity checking performed on binary TIME parameters. - Mailing list pgsql-hackers

From Andrew McNamara
Subject Re: No sanity checking performed on binary TIME parameters.
Date
Msg-id 65B4FAD1-F5A9-4463-8A30-2CD1B62A0B13@object-craft.com.au
Whole thread Raw
In response to Re: No sanity checking performed on binary TIME parameters.  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: No sanity checking performed on binary TIME parameters.  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On 26/05/2009, at 5:41 AM, Tom Lane wrote:
>
> The only place I can find where an oversize time value behaves in a
> seriously bogus fashion is in time_out, or more specifically
> EncodeTimeOnly(): it fails to initialize its output string at all.
> So you could easily get garbage text output, though in my quick tests
> you seem to usually get an empty string instead.  The odds of an  
> actual
> crash seem pretty small, but not quite zero (if somehow there was no
> zero byte up to the end of the stack).

I'm seeing all sorts of odd stuff - typically the last column value  
output, but occasionally other snippets of random data that don't seem  
related to the query.

> My feeling is that the error check in EncodeTimeOnly is just stupid  
> and
> should be removed.  That code will work fine with oversize times (and
> no, it won't overrun the output buffers either).  The callers aren't
> bothering to check for error returns anyway...


I'm not sure it's postgresql's job to police things like this, but  
returning values greater than 24 hours may violate assumptions in user  
code, and I would be worried about potentially causing silent  
failures. Of course, it should no longer be possible to get an illegal  
value into the database, so the risk is low - either a database that  
predates the fix, or database corruption.

Are there any other cases where the binary receive functions are  
missing sanity checks?




pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: generic options for explain
Next
From: Tom Lane
Date:
Subject: Re: No sanity checking performed on binary TIME parameters.