Re: BUG #5773: DEBUG: reaping dead processes DEBUG: server process (PID 10007) was terminated by signal 11: Segme

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).

http://ring.nict.go.jp/archives/misc/db/postgresql/projects/gborg/uniqueidentifier/stable/uniqueidentifier-0.2.tar.gz

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(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> 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
> > 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
>