Search Postgresql Archives

Re: segmentation fault postgres 9.3.5 core dump perlu related ?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Tom,

Thanks very much for the feedback.

It is very likely that the date of the core was 'touched' to make the rebuilt
Postgres binary with symbols play nice with gdb.
Apparently, that was not a great idea based on your comments.

In any case we are better prepared to analyze it on the next instance.
Unfortunately the issue has been in remission since the thanksgiving holiday.

The combination of FreeBSD and postgres had been remarkably stable and
dependable up to very recently. This original bit of logic that we suspect
is related to the event  was originally written in plpgsql.  The logic  needed some access 
to system level info  for which plpgsql had no built in support.
I suspect the 'getaddrinfo' and 'getnameinfo' and 'open' related statements.
The "open" was the last piece added so it does bear the best correlation to the
problem onset.

In checking the thread counts for the backend processes that have executed this logic successfully I only 
see one thread per backend.

Pondering and awaiting an AHA moment. I'll keep the list appraised of any progress on the matter.

Best Regards


Dave Day



-----Original Message-----
From: Tom Lane [mailto:tgl@xxxxxxxxxxxxx] 
Sent: Wednesday, December 03, 2014 3:57 PM
To: Day, David
Cc: pgsql-general@xxxxxxxxxxxxxx
Subject: Re:  segmentation fault postgres 9.3.5 core dump perlu related ?

"Day, David" <dday@xxxxxxxxxx> writes:
> We are developing on and  running Postgres 9.3.5 on  FreeBsd 10.0-p12.
> We have been experiencing a intermittent postgres core dump which 
> Seems primarily to be associated with the the 2  functions below.

> Given the onset of this problem,  we suspect it has something to do with the addition of  DNS lookup within the our  perlu function cc.get_sip_id(...).

So this bit is new?

>     open my $fh, "/sbin/route get $host |";

I wonder if your version of Perl thinks this is sufficient license to go multithreaded or something like that.  That could be problematic.  You might try looking to see if a backend process that's successfully executed this code now contains multiple threads.

It's difficult to offer much help on the basis of the info provided.
One comment is that the stack trace you show is completely nonsensical:
functions by those names do exist in PG, but the calling order shown is impossible.  So it seems there's some problem in how you rebuilt with debug symbols --- maybe the symbols being used don't match the executable?  I'm not a FreeBSD user so I have no useful speculation to offer about how such a mixup might occur on that platform.

			regards, tom lane


-- 
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general





[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]
  Powered by Linux