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
