Re: BUG #5773: DEBUG: reaping dead processes DEBUG: server process (PID 10007) was terminated by signal 11: Segme - Mailing list pgsql-bugs
Thanks all for your help!!
I am not sure that I'll get all my needed function from built-in UUID. I got the source from the below link also this works perfectly fine with 8.3 version(in my understanding).
I am very much excited to use UUID, please let me know if there is any link where i can download and compile all my needed functions, Also I cannot change my function on my production environment in case needed for uuid which might needed long hours of testing and hope some of our application might be in trouble.
Please find the attachment for needed functions.
Again,thanks for everyone who is helping me on this issue.
Thanks,
Bala
On Sun, Nov 28, 2010 at 2:54 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
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 theAh, thanks.
>> source code anymore though.
> How about
> http://www.postgresql.org/ftp/projects/gborg/uniqueidentifier/stable/You're looking at the output function not the input function ... and
>> 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:
indeed the first thing the input function does is to invoke strlen(),
without any null check.It'd be better to mark it STRICT in the SQL file (and likewise for the
> It should use PG_ARGISNULL(0), no?
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
Attachment
pgsql-bugs by date: