[BUGS] BUG #7968: Perl DBI segfaults in connect()
The following bug has been logged on the website:
Bug reference: 7968
Logged by: Mitchell Perilstein
Email address: mperilst...@trueposition.com
PostgreSQL version: 9.1.5
Operating system: SPARC Solaris 10
Description:
Summary: A perl DBI/DBD client makes a connect() call to a db server in down
or restarting state and coredumps. There was a similar stack trace reported
in 2011 but not exactly. I can probably reproduce this more succinctly with
a testcase if needed.
This code (part of Bucardo) was the call:
$dbh = DBI->connect
(
$dsn,
$user,
$pass,
{AutoCommit=>0, RaiseError=>1, PrintError=>0}
);
The perl caller logs this and crashes:
DBI
connect('dbname=TPLocationGateway;port=5432;host=tplocalvirt','tpadmin',...)
failed:
FATAL: database "TPLocationGateway" does not exist at
/tpapp/tpdb/lib/perl5/Bucardo.pm line 4936
The Solaris coredump looks like this:
# pstack core
core 'core' of 18694: perl /tpapp/tpdb/bin/bucardo
--log-destination=/tpdata/tpdb/logs --log
fed60fb0 pg_warn (0, ae3648, 5fb0f0, 2d764, aa0f20, fed60f78) + 38
fed27174 pqGetErrorNotice3 (adb080, 11000, 0, abf545, 0, ffbfed0c) +
4fc
fed260a8 pqParseInput3 (adb080, adb3f4, 4, ffbfed78, fed431ac, 282019)
+ 168
fed1db30 PQgetResult (adb080, adb080, 1, 200, 128808, fed431ac) +
c4
fed726a8 handle_old_async (4bada0, a75548, 100, 800, 64,
fed8e6e0) + 5c4
fed6d088 pg_st_destroy (4bada0, adcf20, 0, 217ec, fed8e6e0, a75548) +
198
fed59af8 XS_DBD__Pg__st_DESTROY (128808, 4, 803948, fed8e6e0, 2245c,
4bada0) + 304
feecec58 XS_DBI_dispatch (803948, c06a8, feeda8b0, feeec0a4, 0, 22460)
+ 20f0
ff2a7634 Perl_pp_entersub (c0db4, 0, ffc0, c2538, ffbff5a0,
ff348000) + 6fc
ff269c2c S_call_body (ffbff5a0, 0, 3000, de41c, 529e50, ff35d978) + 54
ff2698c0 Perl_call_sv (2c00, 2c00, 3050, 26e3c, ff35b3e4, ff35b3c8) +
9cc
ff2f0f8c Perl_sv_clear (8147b0, 3000, 3000, 124be0, ff348000, 41) +
280
ff2f18d0 Perl_sv_free (8147b0, ff2f0c98, 568f8, 8, 0, 8147b0) + 1d8
ff2f14a8 Perl_sv_clear (501f2c, 7d4, ff2f15a8, 0, ff348000, 3000) +
79c
ff2f18d0 Perl_sv_free (501f2c, 7d4, 568f8, ff, 0, 501f2c) + 1d8
ff245628 Perl_mg_free (a5c894, ff35b398, 0, b, 2000900b, 5ffdb8) + ac
ff2f121c Perl_sv_clear (a5c894, 1, 2c00, ff35d97c, ff348000, 0) + 510
ff2f18d0 Perl_sv_free (a5c894, 5fb428, 568f8, ff2e69e4, 0, a5c894) +
1d8
ff2e692c S_visit (ff2e6968, 5fb428, 5fb668, 5fb278, ff348000, 1d7) +
80
ff2e6b28 Perl_sv_clean_objs (2f80, 1, ff34b560, ff348000, 61514, 2c00)
+ 48
ff264c84 perl_destruct (0, 3400, 0, 1, ff35b3ec, 3400) + 2f8
00011050 main (8, ffbffaf4, 0, 22400, 22420, 22400) + b4
00010f84 _start (0, 0, 0, 0, 0, 0) + 108
# pflags core
core 'core' of 18694: perl /tpapp/tpdb/bin/bucardo
--log-destination=/tpdata/tpdb/logs --log
data model = _ILP32 flags = MSACCT|MSFORK
/1:flags = 0
sigmask = 0xbefc,0x cursig = SIGSEGV
Solaris (but we've seen it on similar boxes):
# uname -a
SunOS WilWlg1 5.10 Generic_147440-25 sun4v sparc sun4v
Perl v5.8.4 :
# perl -V
Summary of my perl5 (revision 5 version 8 subversion 4) configuration:
Platform:
osname=solaris, osvers=2.10, archname=sun4-solaris-64int
uname='sunos localhost 5.10 sun4u sparc SUNW,Ultra-2'
config_args=''
hint=recommended, useposix=true, d_sigaction=define
usethreads=undef use5005threads=undef useithreads=undef
usemultiplicity=undef
useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
use64bitint=define use64bitall=undef uselongdouble=undef
usemymalloc=n, bincompat5005=undef
Compiler:
cc='cc', ccflags ='-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
-xarch=v8 -D_TS_ERRNO',
optimize='-xO3 -xspace -xildoff',
cppflags=''
ccversion='Sun WorkShop', gccversion='', gccosandvers=''
intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=87654321
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16
ivtype='long long', ivsize=8, nvtype='double', nvsize=8,
Off_t='off_t', lseeksize=8
alignbytes=8, prototype=define
Linker and Libraries:
ld='cc', ldflags =''
libpth=/lib /usr/lib /usr/ccs/lib
libs=-lsocket -lnsl -ldl -lm -lc
perllibs=-lsocket -lnsl -ldl -lm -lc
libc=/lib/libc.so, so=so, useshrplib=true, libperl=libperl.so
gnulibc_version=''
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-R
/usr/perl5/5.8.4/lib/sun4-solaris-64int/CORE'
cccdlflags='-KPIC', lddlflags='-G'
Characteristics of this binary (from libperl):
Compile-time options: USE_64_BIT_INT USE_LARGE_FILES
Locally applied patches:
22667 The optree builder was looping whe
[BUGS] BUG #7956: Installation fails saying database cluster initialization failed
The following bug has been logged on the website: Bug reference: 7956 Logged by: Nav Email address: navin@gmail.com PostgreSQL version: 9.2.3 Operating system: Windows Description: I've posted the solution to my problem here: http://dba.stackexchange.com/a/36901 It's because somehow, doskey isn't starting on my system (this problem was happening even before I tried installing postgresql), but the point is that it'd help if postgresql installation is made independent of something like doskey. you'd probably be able to reproduce it by deleting doskey.exe from your system and trying to install postgresql (any version) -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #7967: Wrong week number in extract function
The following bug has been logged on the website: Bug reference: 7967 Logged by: Pawel Kobylak Email address: no...@noose.pl PostgreSQL version: 9.1.3 Operating system: Debian Description: Hi, I'm running that query and result is ... unexpected for me... Query: select '2012-12-31', EXTRACT(year from '2012-12-31'::date), EXTRACT(week from '2012-12-31'::date) Result: "2012-12-31";2012;1 Expected: "2012-12-31";2012;53 OR "2012-12-31";2013;1 This result is correct? Or that is little bug? :-) Regards, Pawel -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #7968: Perl DBI segfaults in connect()
mperilst...@trueposition.com writes: > Summary: A perl DBI/DBD client makes a connect() call to a db server in down > or restarting state and coredumps. The stack trace looks like the problem is in a notice handler installed by DBD-Pg, not in libpq proper. I'm not sure that the authors of DBD-Pg read pgsql-bugs --- you might want to contact them another way. The bug tracker at http://search.cpan.org/dist/DBD-Pg/ might be a good bet. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #7968: Perl DBI segfaults in connect()
Mitchell Perilstein writes: > Yes, that was a better place to look. They have it already: > https://rt.cpan.org/Public/Bug/Display.html?id=69664 Looks like they don't know how to reproduce it though, so you could help them out by adding a test case there. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #7967: Wrong week number in extract function
no...@noose.pl wrote on 18.03.2013 09:23: The following bug has been logged on the website: Bug reference: 7967 Logged by: Pawel Kobylak Email address: no...@noose.pl PostgreSQL version: 9.1.3 Operating system: Debian Description: Hi, I'm running that query and result is ... unexpected for me... Query: select '2012-12-31', EXTRACT(year from '2012-12-31'::date), EXTRACT(week from '2012-12-31'::date) Result: "2012-12-31";2012;1 Expected: "2012-12-31";2012;53 OR "2012-12-31";2013;1 This result is correct? Or that is little bug? :-) Regards, Pawel Expected - or at least documented. You are looking for "isoyear" instead of "year": select extract(isoyear from date '2012-12-31') Result: 2013 The same "option" is available for the to_char() function: IYYY vs. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #7967: Wrong week number in extract function
no...@noose.pl writes: > I'm running that query and result is ... unexpected for me... > Query: > select '2012-12-31', EXTRACT(year from '2012-12-31'::date), EXTRACT(week > from '2012-12-31'::date) It's correct, because "week" follows the ISO definition of week counting. According to that, 2012-12-31 falls in the first week of 2013. (I have no idea how ISO arrived at their definition, but this is what it says: weeks start on Mondays, and the first week of a year is the one containing January 4.) You should usually use isoyear when you are using week, so that the results sync up. This is all explained in http://www.postgresql.org/docs/9.1/static/functions-datetime.html#FUNCTIONS-DATETIME-EXTRACT although I notice that the explanation of "week" fails to show explicitly that late-December dates can be considered to fall into the next year. I'll go fix that. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #7968: Perl DBI segfaults in connect()
Yes, that was a better place to look. They have it already: https://rt.cpan.org/Public/Bug/Display.html?id=69664 Thanks! On 03/18/2013 12:33 PM, Tom Lane wrote: mperilst...@trueposition.com writes: Summary: A perl DBI/DBD client makes a connect() call to a db server in down or restarting state and coredumps. The stack trace looks like the problem is in a notice handler installed by DBD-Pg, not in libpq proper. I'm not sure that the authors of DBD-Pg read pgsql-bugs --- you might want to contact them another way. The bug tracker at http://search.cpan.org/dist/DBD-Pg/ might be a good bet. regards, tom lane Confidentiality Notice: This e-mail (including any attachments) is intended only for the recipients named above. It may contain confidential or privileged information and should not be read, copied or otherwise used by any other person. If you are not a named recipient, please notify the sender of that fact and delete the e-mail from your system. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #7969: Postgres Recovery Fatal With: "incorrect local pin count: 2"
The following bug has been logged on the website: Bug reference: 7969 Logged by: Yunong Xiao Email address: yjx...@gmail.com PostgreSQL version: 9.2.2 Operating system: SmartOS (Solaris) Description: I have an instance of postgresql 9.2.2 running on Solaris. At some point the zone the postgresql was running on was restarted (effectively a power cycle) and postgresql consistently crashes on recovery with the following log snippet: (full log and postgresql.conf attached at the end of this email) 2013-03-15 22:00:49.510 UTCLOG: database system was not properly shut down; automatic recovery in progress 2013-03-15 22:00:49.510 UTCDEBUG: resetting unlogged relations: cleanup 1 init 0 2013-03-15 22:00:49.511 UTCLOG: redo starts at 0/551EC58 2013-03-15 22:00:49.515 UTCDEBUG: page 10 of relation base/16384/1 does not exist 2013-03-15 22:00:49.515 UTCCONTEXT: xlog redo update: rel 1663/16384/1; tid 8/4; new 10/5 2013-03-15 22:00:49.515 UTCFATAL: incorrect local pin count: 2 I am running postgres on ZFS with fsync=on, which as far as I can tell, guarantees that there can be no data corruption. I have included the postgres data directory as a tarball here: https://download.joyent.com/pub/postgresql/corrupted-pg.tar and this problem can be reproduced by untarring the data directory and running as the postgres user `postgres -D ` Full postgresql logs: 2013-03-15 22:00:49.509 UTCLOG: database system was interrupted while in recovery at 2013-03-15 21:55:49 UTC 2013-03-15 22:00:49.509 UTCHINT: This probably means that some data is corrupted and you will have to use the last backup for recovery. 2013-03-15 22:00:49.510 UTCDEBUG: checkpoint record is at 0/551F6B0 2013-03-15 22:00:49.510 UTCDEBUG: redo record is at 0/551EC58; shutdown FALSE 2013-03-15 22:00:49.510 UTCDEBUG: next transaction ID: 0/1693; next OID: 24576 2013-03-15 22:00:49.510 UTCDEBUG: next MultiXactId: 1; next MultiXactOffset: 0 2013-03-15 22:00:49.510 UTCDEBUG: oldest unfrozen transaction ID: 665, in database 1 2013-03-15 22:00:49.510 UTCDEBUG: transaction ID wrap limit is 2147484312, limited by database with OID 1 2013-03-15 22:00:49.510 UTCLOG: database system was not properly shut down; automatic recovery in progress 2013-03-15 22:00:49.510 UTCDEBUG: resetting unlogged relations: cleanup 1 init 0 2013-03-15 22:00:49.511 UTCLOG: redo starts at 0/551EC58 2013-03-15 22:00:49.515 UTCDEBUG: page 10 of relation base/16384/1 does not exist 2013-03-15 22:00:49.515 UTCCONTEXT: xlog redo update: rel 1663/16384/1; tid 8/4; new 10/5 2013-03-15 22:00:49.515 UTCFATAL: incorrect local pin count: 2 2013-03-15 22:00:49.515 UTCCONTEXT: xlog redo clean: rel 1663/16384/1; blk 8 remxid 1729 2013-03-15 22:00:49.515 UTCDEBUG: shmem_exit(1): 4 callbacks to make 2013-03-15 22:00:49.515 UTCDEBUG: proc_exit(1): 2 callbacks to make 2013-03-15 22:00:49.515 UTCDEBUG: exit(1) 2013-03-15 22:00:49.515 UTCDEBUG: shmem_exit(-1): 0 callbacks to make 2013-03-15 22:00:49.515 UTCDEBUG: proc_exit(-1): 0 callbacks to make 2013-03-15 22:00:49.518 UTCDEBUG: reaping dead processes 2013-03-15 22:00:49.518 UTCLOG: startup process (PID 23162) exited with exit code 1 2013-03-15 22:00:49.518 UTCLOG: aborting startup due to startup process failure 2013-03-15 22:00:49.518 UTCDEBUG: shmem_exit(1): 3 callbacks to make 2013-03-15 22:00:49.524 UTCDEBUG: proc_exit(1): 3 callbacks to make 2013-03-15 22:00:49.524 UTCDEBUG: exit(1) 2013-03-15 22:00:49.524 UTCDEBUG: shmem_exit(-1): 0 callbacks to make 2013-03-15 22:00:49.524 UTCDEBUG: proc_exit(-1): 0 callbacks to make 2013-03-15 22:00:49.526 UTCDEBUG: logger shutting down 2013-03-15 22:00:49.526 UTCDEBUG: shmem_exit(0): 0 callbacks to make 2013-03-15 22:00:49.526 UTCDEBUG: proc_exit(0): 0 callbacks to make 2013-03-15 22:00:49.527 UTCDEBUG: exit(0) 2013-03-15 22:00:49.527 UTCDEBUG: shmem_exit(-1): 0 callbacks to make 2013-03-15 22:00:49.527 UTCDEBUG: proc_exit(-1): 0 callbacks to make postgresql-2013-03-15_220049.log (END) postgresql.conf listen_addresses = '0.0.0.0' # what IP address(es) to listen on; port = 5432# (change requires restart) max_connections = 100 # (change requires restart) shared_buffers = 32MB # min 128kB wal_level = hot_standby # minimal, archive, or hot_standby fsync = on # turns forced synchronization on or off synchronous_commit = remote_write full_page_writes = off # recover from partial page writes max_wal_senders = 15# max number of walsender processes wal_keep_segments = 1000# in logfile segments, 16MB each; 0 disables synchronous_standby_names = '' # standby servers that provide sync rep hot_standby = on # "on" allows queries during recovery max_standby_archive_delay = 30s # max delay before canceling queries max_standby_streaming_delay = 30s # max delay before canceling queries wal_receiver_status_interval = 10s # send replies at least this often hot_standby_feedback = off # send info from standby t
