On Thu, Feb 10, 2011 at 03:24, Sam Stearns <samtstearns(at)gmail(dot)com> wrote:
> Thanks, Norbert!
> I'll run the perl 5.10 upgrade past the guys.
> On Thu, Feb 10, 2011 at 6:27 PM, Norbert Zacharias <zac(at)uni-oldenburg(dot)de> wrote:
>>>> perl -V
>>> Summary of my perl5 (revision 5 version 8 subversion 8) configuration:
>> May be an upgrade to 5.10 will solve the problem ?
>> From gdb:
>> #0 0x080bf4ef in Perl_sv_vcatpvfn ()
>> #1 0x080bdb30 in Perl_sv_vsetpvfn ()
>> #2 0x080a1363 in Perl_vmess ()
>> #3 0x080a1d06 in Perl_vwarn ()
>> #4 0x080a1fde in Perl_warn ()
>> #5 0xfe7f9d58 in pg_warn () from /usr/local/stow/perl-5.8.8/lib/site_perl/5.8.8/i86pc-solaris/auto/DBD/Pg/Pg.so
>> #6 0xfe7c704e in defaultNoticeReceiver () from /usr/local/lib/libpq.so.4
>> #7 0xfe7cf0bc in pqGetErrorNotice3 () from /usr/local/lib/libpq.so.4
So it looks like it you are receiving a notice and DBD::Pg is trying
to warn() it.
What versions of DBD::Pg and DBI are you using? I'd look at
http://search.cpan.org/~timb/DBI-1.616/Changes for any known bugs you
might be hitting.
If upgrading those do not fix it, the next step would be to try and
make a reproducible test case. I'd start by by cranking up the
postgres log level so you can find out what the notice is. From there
you might be able to find a way to trigger it reliably.
If all else fails it never hurts to run it under valgrind to see if it
can pinpoint some obvious memory corruption.
In response to
pgsql-admin by date
|Next:||From: Frederiko Costa||Date: 2011-02-11 17:09:48|
|Subject: Re: Postgres on NAS/NFS|
|Previous:||From: Arnold, Sandra||Date: 2011-02-11 15:32:39|
|Subject: Vulnerability Scanning for PostgreSQL|