From: | Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | frankpit(at)pop(dot)dn(dot)net (Bernard Frankpitt) |
Cc: | hackers(at)postgreSQL(dot)org (PostgreSQL-development) |
Subject: | Re: postgres bug? |
Date: | 1999-02-05 17:48:05 |
Message-ID: | 199902051748.MAA06536@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
You are correct. I have modified the current sources. Good eye.
> Hi Bruce,
> I've been looking over the code in .../backend/utils/adt/selfuncs.c
> and there are a number of functions in there like btreesel() that have
> code
> like this
>
> float64
> btreesel(...)
> {
> float64 result;
> float64data resultData;
>
> ...
> ...
>
> resultData = 1.0/3.0;
> result = &resultData;
>
> ...
> ...
>
> return result;
> }
>
> I don't pretend to understand all the contextual details about how the
> function is used, but It seems that the return result is a pointer to an
> invalid stack location. The storage is allocated as auto storage during
> the function call, and with dynamic range restricted to the execution
> of the function body.
>
> The same thing is used in hashsel() as well, though not in btreenpage()
> which
> uses palloc() to allocate heap storage for the result.
>
> Sorry for the informal form of the notice, but the machine that I work
> on is a long way from the internet, and that makes compiling and mailing
> a patch a pain.
>
> Bernie
>
--
Bruce Momjian | http://www.op.net/~candle
maillist(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 1999-02-05 18:07:46 | Re: SELECT INTO TABLE busted? |
Previous Message | Tom Lane | 1999-02-05 17:36:48 | Re: [INTERFACES] Postgres Limitations |