Re: [HACKERS] FreeBSD problem under heavy load
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] FreeBSD problem under heavy load |
Дата | |
Msg-id | 17219.944809086@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] FreeBSD problem under heavy load (Tatsuo Ishii <t-ishii@sra.co.jp>) |
Ответы |
Re: [HACKERS] FreeBSD problem under heavy load
|
Список | pgsql-hackers |
Tatsuo Ishii <t-ishii@sra.co.jp> writes: > The current status string is copied into old_status, then the pointer > to it is set to a gloable variable ps_status by PS_SET_STATUS > macro. Unfortunately old_status is on the stack, so once WaitOnLock > returns, ps_status would point to a garbage. In the subsequent call to > WaitOnLock, > strcpy(old_status, PS_STATUS); > will copy garbage string into old_status. So if the string is longer > than 63, the stack would be broken. Note that this would not happen on > Linux due to the difference of the definition of the macro. See > include/utils/ps_status.h for more details. Ugh. It wouldn't happen on HPUX either, because the PS_STATUS stuff all compiles as no-ops here. So that's why I couldn't see it. You didn't say what you had in mind to fix this, but I think the safest approach would be to reserve an area to copy the PS_SET_STATUS string into on *all* systems. Otherwise we'll just get bitten by this kind of bug again in future. > BTW, I think pgbench is usefull to detect this kind of problems. Can I > put it into contrib or somewhere? Sounds like a good idea to me. regards, tom lane
В списке pgsql-hackers по дате отправления: