Re: BUG #5773: DEBUG: reaping dead processes DEBUG: server process (PID 10007) was terminated by signal 11: Segme
От | Tom Lane |
---|---|
Тема | Re: BUG #5773: DEBUG: reaping dead processes DEBUG: server process (PID 10007) was terminated by signal 11: Segme |
Дата | |
Msg-id | 1878.1290893095@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: BUG #5773: DEBUG: reaping dead processes DEBUG: server process (PID 10007) was terminated by signal 11: Segme (Joshua Tolley <eggyknap@gmail.com>) |
Ответы |
Re: BUG #5773: DEBUG: reaping dead processes DEBUG: server
process (PID 10007) was terminated by signal 11: Segme
|
Список | pgsql-bugs |
Joshua Tolley <eggyknap@gmail.com> writes: > On Sat, Nov 27, 2010 at 11:23:46AM -0500, Tom Lane wrote: >> There used to be a project of that name on gborg. I can't find the >> source code anymore though. > How about > http://www.postgresql.org/ftp/projects/gborg/uniqueidentifier/stable/ Ah, thanks. >> The magic-block mechanism should prevent that. What I'm wondering about >> is whether the input function is (a) careless about null input and (b) >> not marked STRICT. > I think you're right: You're looking at the output function not the input function ... and indeed the first thing the input function does is to invoke strlen(), without any null check. > It should use PG_ARGISNULL(0), no? It'd be better to mark it STRICT in the SQL file (and likewise for the output function). Or actually what he *should* do is drop the whole thing and use the now-built-in uuid type. Now, this 2003-vintage tarball is obviously not what the OP is using, since it hasn't even got a PG_MODULE_MAGIC call. But if it hasn't been updated any more than that, this'd explain a core dump on NULL input. What's a bit less clear is how the null got into the source database without having triggered the same bug; but I suppose it might've been generated via INSERT DEFAULT VALUES or some such. regards, tom lane
В списке pgsql-bugs по дате отправления: