Joshua Tolley <eggyknap(at)gmail(dot)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
>> 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
In response to
pgsql-bugs by date
|Next:||From: Bala Murugan||Date: 2010-11-28 07:25:52|
|Subject: BUG #5774: VACCUM & REINDEX kills production environement|
|Previous:||From: Joshua Tolley||Date: 2010-11-27 21:11:50|
|Subject: Re: BUG #5773: DEBUG: reaping dead processes DEBUG: serverprocess (PID 10007) was terminated by signal 11: Segme|