Re: [BUGS] BUG #1270: stack overflow in thread in fe_getauthname

Поиск
Список
Период
Сортировка
От Peter Davie
Тема Re: [BUGS] BUG #1270: stack overflow in thread in fe_getauthname
Дата
Msg-id 416F0421.1030804@relevance.com.au
обсуждение исходный текст
Ответ на Re: [BUGS] BUG #1270: stack overflow in thread in fe_getauthname  (Bruce Momjian <pgman@candle.pha.pa.us>)
Список pgsql-hackers
Hi Bruce,<br /><br /> That would work!<br /><br /> Thanks<br /> Peter<br /><br /> Bruce Momjian wrote: <blockquote
cite="mid200410142030.i9EKU2421482@candle.pha.pa.us"type="cite"><pre wrap="">One idea would be to use malloc() to
allocatestorage for the
 
thread-safe buffers when compiled with thread-safety, rather than using
the stack.

---------------------------------------------------------------------------

Peter Davie wrote: </pre><blockquote type="cite"><pre wrap="">Hi Tom,

How many of these platforms you use are POSIX-compliant?  This 
information came from the POSIX web site (NOT THE DIGITAL/COMPAQ/HP/... 
WEBSITE).  Sysconf(_SC_GETPW_R_SIZE_MAX)  is supported by Solaris 2.5, 
SCO UNIX (circa 1999!),  Digital UNIX/Compaq Tru64 UNIX, FreeBSD,  AIX, 
HP-UX, and probably many more.

Maybe the non-compliant platforms should be catered for as "legacy" with 
support code in the "ports" area, and those that do adhere to open 
standards can be accommodated without breaking existing production 
applications.

Thanks
Peter

Tom Lane wrote:
   </pre><blockquote type="cite"><pre wrap="">Bruce Momjian <a class="moz-txt-link-rfc2396E"
href="mailto:pgman@candle.pha.pa.us"><pgman@candle.pha.pa.us></a>writes:
 
     </pre><blockquote type="cite"><pre wrap="">OK, we got a report.  I just thinkg 8192 is excessive for that
structure, and if someone is having a problem, others might as well.  
       </pre></blockquote><pre wrap=""> 
     </pre><blockquote type="cite"><blockquote type="cite"><pre wrap="">On Tru64 UNIX, sysconf(_SC_GETPW_R_SIZE_MAX)
returns1024.    
 
         </pre></blockquote></blockquote><pre wrap="">I'd be more impressed by this line of reasoning if
_SC_GETPW_R_SIZE_MAX
were defined on more than one of the platforms I use...
        regards, tom lane
     </pre></blockquote><pre wrap="">
--                           Relevance... because results count

Relevance                               Phone:  +61 (0)2 6241 6400
A.B.N. 86 063 403 690                   Fax:    +61 (0)2 6241 6422
Unit 11, Mitchell Commercial Centre,    Mobile: +61 (0)417 265 175
cnr Brookes and Heffernan Sts.,         E-mail: <a class="moz-txt-link-abbreviated"
href="mailto:peter.davie@relevance.com.au">peter.davie@relevance.com.au</a>
Mitchell ACT 2911                       Web:    <a class="moz-txt-link-freetext"
href="http://www.relevance.com.au">http://www.relevance.com.au</a>
   </pre></blockquote><pre wrap=""> </pre></blockquote><br /><br /><pre class="moz-signature" cols="72">--
            Relevance... because results count
 

Relevance                               Phone:  +61 (0)2 6241 6400
A.B.N. 86 063 403 690                   Fax:    +61 (0)2 6241 6422
Unit 11, Mitchell Commercial Centre,    Mobile: +61 (0)417 265 175
cnr Brookes and Heffernan Sts.,         E-mail: <a class="moz-txt-link-abbreviated"
href="mailto:peter.davie@relevance.com.au">peter.davie@relevance.com.au</a>
Mitchell ACT 2911                       Web:    <a class="moz-txt-link-freetext"
href="http://www.relevance.com.au">http://www.relevance.com.au</a></pre>

В списке pgsql-hackers по дате отправления:

Предыдущее
От: gevik@xs4all.nl
Дата:
Сообщение: embedded postgresql
Следующее
От: Neil Conway
Дата:
Сообщение: Re: spinlocks: generalizing "non-locking test"