Skip site navigation (1) Skip section navigation (2)

Re: leakproof

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, Don Baccus <dhogaza(at)pacifier(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: leakproof
Date: 2012-02-22 15:56:50
Message-ID: 4F451042.9000406@dunslane.net (view raw or flat)
Thread:
Lists: pgsql-hackers

On 02/22/2012 10:21 AM, Tom Lane wrote:
> Robert Haas<robertmhaas(at)gmail(dot)com>  writes:
>> Anyway, to your point, I suppose I might hesitate to mark factorial
>> leak-proof even if it didn't throw an error on overflow, because the
>> time it takes to return an answer for larger inputs does grow rather
>> rapidly.  But it's kind of a moot point because the error makes it not
>> leak-proof anyway.  So maybe we're just splitting hairs here, however
>> we decide to label this.
> Speaking of hair-splitting ...
>
> A strict interpretation of "no errors can be thrown" would, for example,
> rule out any function that either takes or returns a varlena datatype,
> since those are potentially going to throw out-of-memory errors if they
> can't palloc a result value or a temporary detoasted input value.
> I don't suppose that we want that, which means that this rule of thumb
> is wrong in detail, and there had better be some more subtle definition
> of what is okay or not, perhaps along the line of "must not throw any
> errors that reveal anything useful about the input value".  Have we got
> such a definition?  (I confess to not having followed this patch very
> closely.)
>
> 			

Yeah.

Returning to the original point, I've come to the conclusion that "pure" 
isn't the right way to go. The trouble with "leakproof" is that it 
doesn't point to what it is that's not leaking, which is information 
rather than memory, as many might imagine (and I did) without further 
hints. I'm not sure any single English word would be as descriptive as 
I'd like.

cheers

andrew

In response to

Responses

pgsql-hackers by date

Next:From: Magnus HaganderDate: 2012-02-22 16:02:39
Subject: Re: pg_basebackup -x stream from the standby gets stuck
Previous:From: ktm@rice.eduDate: 2012-02-22 15:35:51
Subject: Re: VACUUM ANALYZE is faster than ANALYZE?

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group