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@sss.pgh.pa.us]
Sent: Wednesday, December 03, 2014 3:57 PM
To: Day, David
Cc: pgsql-general@postgresql.org
Subject: Re: [GENERAL] segmentation fault postgres 9.3.5 core dump perlu related ?
"Day, David" <dday@redcom.com> 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
perlufunction 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
couldbe problematic. You might try looking to see if a backend process that's successfully executed this code now
containsmultiple 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
inhow you rebuilt with debug symbols --- maybe the symbols being used don't match the executable? I'm not a FreeBSD
userso I have no useful speculation to offer about how such a mixup might occur on that platform.
regards, tom lane
