Skip site navigation (1) Skip section navigation (2)

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

From: Balamurugan Mahendran <balamurugan(at)adaptavant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Joshua Tolley <eggyknap(at)gmail(dot)com>, Magnus Hagander <magnus(at)hagander(dot)net>, Craig Ringer <craig(at)postnewspapers(dot)com(dot)au>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #5773: DEBUG: reaping dead processes DEBUG: server process (PID 10007) was terminated by signal 11: Segme
Date: 2010-11-28 08:01:00
Message-ID: (view raw, whole thread or download thread mbox)
Lists: 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.


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

Attachment: uniqueidentifier.sql
Description: application/octet-stream (4.3 KB)

In response to


pgsql-bugs by date

Next:From: Robert HaasDate: 2010-11-28 12:56:37
Subject: Re: BUG #5763: pg_hba.conf not honored
Previous:From: Bala MuruganDate: 2010-11-28 07:25:52
Subject: BUG #5774: VACCUM & REINDEX kills production environement

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group