[HACKERS] build farm machine using make -j 8 mixed results
I change the build-farm.conf file to have the following make line: make = 'make -j 8', # or gmake if required. can include path if necessary. 2 pass, 4 fail. Is this a build configuration you want to pursue? I can either create a new machine, or change one of my existing machines. Makes no difference to me. roberts-imac:build-farm-4.7-j robert$ time ./run_branches.pl --run-all --test Sat Sep 1 09:26:49 2012: buildfarm run for CHANGEME:HEAD starting [09:26:49] checking out source ... [09:27:59] checking if build run needed ... [09:27:59] copying source to pgsql.54279 ... [09:28:03] running configure ... [09:28:25] running make ... [09:28:45] running make check ... Branch: HEAD Stage Check failed with status 2 Sat Sep 1 09:29:09 2012: buildfarm run for CHANGEME:REL9_2_STABLE starting [09:29:09] checking out source ... [09:29:57] checking if build run needed ... [09:29:57] copying source to pgsql.70926 ... [09:29:58] running configure ... [09:30:18] running make ... [09:30:45] running make check ... [09:31:09] running make contrib ... [09:31:12] running make install ... [09:31:15] running make contrib install ... [09:31:16] setting up db cluster (C)... [09:31:19] starting db (C)... [09:31:20] running make installcheck (C)... [09:31:39] restarting db (C)... [09:31:51] running make isolation check ... [09:32:00] restarting db (C)... [09:32:12] running make PL installcheck (C)... Branch: REL9_2_STABLE Stage PLCheck-C failed with status 2 Sat Sep 1 09:32:29 2012: buildfarm run for CHANGEME:REL9_1_STABLE starting [09:32:29] checking out source ... [09:33:08] checking if build run needed ... [09:33:08] copying source to pgsql.94883 ... [09:33:10] running configure ... [09:33:30] running make ... [09:33:54] running make check ... [09:34:18] running make contrib ... [09:34:21] running make install ... [09:34:23] running make contrib install ... [09:34:24] setting up db cluster (C)... [09:34:26] starting db (C)... [09:34:27] running make installcheck (C)... [09:34:47] restarting db (C)... [09:34:59] running make isolation check ... [09:35:16] restarting db (C)... [09:35:28] running make PL installcheck (C)... Branch: REL9_1_STABLE Stage PLCheck-C failed with status 2 Sat Sep 1 09:35:46 2012: buildfarm run for CHANGEME:REL9_0_STABLE starting [09:35:46] checking out source ... [09:36:08] checking if build run needed ... [09:36:08] copying source to pgsql.18851 ... [09:36:10] running configure ... [09:36:28] running make ... [09:37:00] running make check ... [09:37:23] running make contrib ... [09:37:27] running make install ... [09:37:30] running make contrib install ... [09:37:32] setting up db cluster (C)... [09:37:34] starting db (C)... [09:37:35] running make installcheck (C)... [09:37:52] restarting db (C)... [09:38:04] running make PL installcheck (C)... [09:38:06] restarting db (C)... [09:38:18] running make contrib installcheck (C)... [09:38:30] stopping db (C)... [09:38:31] running make ecpg check ... [09:38:43] OK Branch: REL9_0_STABLE All stages succeeded Sat Sep 1 09:38:43 2012: buildfarm run for CHANGEME:REL8_4_STABLE starting [09:38:43] checking out source ... [09:38:57] checking if build run needed ... [09:38:57] copying source to pgsql.45071 ... [09:38:59] running configure ... [09:39:19] running make ... [09:39:46] running make check ... [09:40:14] running make contrib ... [09:40:17] running make install ... [09:40:23] running make contrib install ... [09:40:25] setting up db cluster (C)... [09:40:30] starting db (C)... [09:40:31] running make installcheck (C)... [09:40:47] restarting db (C)... [09:40:59] running make PL installcheck (C)... [09:41:01] restarting db (C)... [09:41:13] running make contrib installcheck (C)... [09:41:25] stopping db (C)... [09:41:26] running make ecpg check ... [09:41:44] OK Branch: REL8_4_STABLE All stages succeeded Sat Sep 1 09:41:44 2012: buildfarm run for CHANGEME:REL8_3_STABLE starting [09:41:44] checking out source ... [09:42:39] checking if build run needed ... [09:42:39] copying source to pgsql.80222 ... [09:42:42] running configure ... [09:43:03] running make ... [09:43:38] running make check ... [09:44:04] running make contrib ... [09:44:09] running make install ... [09:44:14] running make contrib install ... [09:44:17] setting up db cluster (C)... [09:44:20] starting db (C)... [09:44:21] running make installcheck (C)... [09:44:39] restarting db (C)... [09:44:51] running make PL installcheck (C)... [09:44:52] restarting db (C)... [09:45:05] running make contrib installcheck (C)... Branch: REL8_3_STABLE Stage ContribCheck-C failed with status 2
Re: [HACKERS] Build failures with Mountain Lion
On Jul 27, 2012, at 3:26 PM, Tom Lane t...@sss.pgh.pa.us wrote: Hm. We have seen similar symptoms reported by people using broken openssl installations. I've never tracked down the details but I suspect header-vs-library mismatches. Is it possible there are some pre-ML openssl-related files hanging about on your machine? Sigh. I remember now. Having macports in the path before /usr/ horks up the config vs the libraries. Forgetfully yours, Rob -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pg_crypto failures with llvm on OSX
On Mar 10, 2012, at 4:19 PM, Andrew Dunstan and...@dunslane.net wrote: On 03/09/2012 07:50 PM, Tom Lane wrote: Andrew Dunstanand...@dunslane.net writes: Buildfarm member mussel (OS X 10.7.3, llvm-gcc 4.2.1, x86_64)seems to be getting consistent warnings when running the pgcrypto regression tests, that look like this: WARNING: detected write past chunk end in ExprContext 0x7fec2b11eb58 Does anyone have an idea why that might be? Worksforme, on an up-to-date Lion system using exactly the same compiler version. I do see the deprecation warnings (which Apple seems to have plastered on every single OpenSSL function ... doesn't leave me with a warm feeling about their future plans). I suspect that mussel has an ABI-incompatible openssl library hanging around someplace. On my machine otool -L pgcrypto.so shows /usr/lib/libcrypto.0.9.8.dylib (compatibility version 0.9.8, current version 44.0.0) It'd be interesting to know what it says on mussel. Robert, please investigate. creagers-imac:pgcrypto Robert$ otool -L pgcrypto.so pgcrypto.so: /opt/local/lib/libcrypto.1.0.0.dylib (compatibility version 1.0.0, current version 1.0.0) /opt/local/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.5) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 159.1.0) via Mac Ports cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pg_crypto failures with llvm on OSX
On Mar 10, 2012, at 5:01 PM, Tom Lane t...@sss.pgh.pa.us wrote: What's really odd though is that there is nothing in the configuration script that injects any of those switches. I think you've got some screwy global configuration on that machine, which you'd be well advised to try to get rid of --- it's tough for people to do remote diagnosis of buildfarm critters when there's relevant configuration that's not exposed in the config script. No global config. Changed the path around to have /opt/local after the standard Apple ones, and it appears to be working fine. autoconf must be throwing in that path based on executables found? Later, Rob -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pg_crypto failures with llvm on OSX
On Mar 10, 2012, at 7:15 PM, Tom Lane t...@sss.pgh.pa.us wrote: Robert Creager rob...@logicalchaos.org writes: On Mar 10, 2012, at 5:01 PM, Tom Lane t...@sss.pgh.pa.us wrote: What's really odd though is that there is nothing in the configuration script that injects any of those switches. I think you've got some screwy global configuration on that machine, which you'd be well advised to try to get rid of --- it's tough for people to do remote diagnosis of buildfarm critters when there's relevant configuration that's not exposed in the config script. No global config. Changed the path around to have /opt/local after the standard Apple ones, and it appears to be working fine. autoconf must be throwing in that path based on executables found? I don't believe autoconf would insert such stuff on its own authority. I'm wondering about CPPFLAGS, CFLAGS, LDFLAGS or similar variables being set in the environment that the buildfarm script is running in. Take a look at ~/.bash_profile and suchlike files. Nope. Only PATH is set. Later, Rob -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pg_crypto failures with llvm on OSX
On Mar 10, 2012, at 7:54 PM, Andrew Dunstan and...@dunslane.net wrote: On 03/10/2012 09:15 PM, Tom Lane wrote: (I wonder whether it'd be a good idea for the buildfarm script to explicitly clear anything that autoconf pays attention to from its startup environment, so that you have to set these variables in the buildfarm config to make them have effect. If not that, maybe print env output to document what the situation is?) I can put the latter in the next client release, unless people think it's a bit insecure to report arbitrary environment values. If we were to clear them, which would we clear? Why it just report the pertinent ones? Rob -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [Pgbuildfarm-members] CREATE FUNCTION hang on test machine polecat on HEAD
=0x1010064d0 perl_elog, procNamespace=2200, replace=1 '\001', returnsSet=0 '\0', returnType=2278, languageObjectId=41363, languageValidator=41362, prosrc=0x101006958 \n\n my $msg = shift;\n elog(NOTICE,$msg);\n\n, probin=0x0, isAgg=0 '\0', isWindowFunc=0 '\0', security_definer=0 '\0', isStrict=0 '\0', volatility=118 'v', parameterTypes=0x10100d7d8, allParameterTypes=0, parameterModes=0, parameterNames=0, parameterDefaults=0x0, proconfig=0, procost=100, prorows=0) at pg_proc.c:653 #10 0x000100105aae in CreateFunction (stmt=0x101006ab8, queryString=0x101005a38 create or replace function perl_elog(text) returns void language plperl as $$\n\n my $msg = shift;\n elog(NOTICE,$msg);\n\n$$;) at functioncmds.c:942 #11 0x00010023839b in MemoryContextSwitchTo [inlined] () at /Volumes/High Usage/usr/local/src/build-farm-4.4/builds/HEAD/pgsql.4091/src/include/utils/palloc.h:1184 #12 0x00010023839b in PortalRunUtility (portal=0x101027238, utilityStmt=0x101006ab8, isTopLevel=value temporarily unavailable, due to optimizations, dest=0x101006e60, completionTag=0x7fff5fbfdea0 ) at pquery.c:1192 #13 0x000100239b55 in PortalRunMulti (portal=0x101027238, isTopLevel=value temporarily unavailable, due to optimizations, dest=0x101006e60, altdest=0x101006e60, completionTag=0x7fff5fbfdea0 ) at pquery.c:1315 #14 0x00010023a508 in PortalRun (portal=0x101027238, count=9223372036854775807, isTopLevel=value temporarily unavailable, due to optimizations, dest=0x101006e60, altdest=0x101006e60, completionTag=0x7fff5fbfdea0 ) at pquery.c:813 #15 0x0001002364bd in exec_simple_query (query_string=0x101005a38 create or replace function perl_elog(text) returns void language plperl as $$\n\n my $msg = shift;\n elog(NOTICE,$msg);\n\n$$;) at postgres.c:1018 #16 0x000100237081 in PostgresMain (argc=2, argv=value temporarily unavailable, due to optimizations, username=value temporarily unavailable, due to optimizations) at postgres.c:3924 #17 0x0001001e9bbc in ServerLoop () at postmaster.c:3605 #18 0x0001001eab37 in PostmasterMain (argc=3, argv=0x100800680) at postmaster.c:1120 #19 0x00010017db45 in main (argc=3, argv=0x100800680) at main.c:199 -- inline: oracle_sig_logo.gif Robert Creager, Principal Software Engineer Oracle Server Technologies 500 Eldorado Blvd, Bldg 5 Broomfield, CO, 80021 Phone: 303-272-6830 Email: robert.crea...@oracle.com inline: green-for-email-sig_0.gifOracle is committed to developing practices and products that help protect the environment -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Why polecat and colugos are failing to build back branches
On Jun 15, 2011, at 7:51 PM, Tom Lane t...@sss.pgh.pa.us wrote: ... installation paths. About the only good thing to be said about it is that these characters are so troublesome that Unix users are unlikely to use them in directory names anyway. So I'm guessing you don't want this path name? I was going to throw some \n and in it also, maybe some *,' and for good measure -) Shall I just stick with spaces? drwxr-xr-x 2 Robert wheel68B Jun 15 17:26 pg bu!ldfa$m\a\$y/ Robert-Creagers-iMac:src Robert$ Later, Rob -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Polecat quit unexpectdly
On Jun 14, 2011, at 2:11 PM, Kevin Grittner wrote: Robert Creager robert.crea...@oracle.com wrote: Stack trace, nothing else. 3 postgres 0x00010005cafa multixact_twophase_postcommit + 74 (multixact.c:1367) 4 postgres 0x00010005deab ProcessRecords + 91 (twophase.c:1407) 5 postgres 0x00010005f78a FinishPreparedTransaction + 1610 (twophase.c:1368) If this was a checkout from more than about 7 hours ago and less than about 10 hours ago, please get a fresh copy of the source and try again. You believe it was related to the flurry of errors that popped up then. This machine updates git every 30 minutes, runs builds every 2 hours, forces HEAD every 6 hours. Later, Rob -- inline: oracle_sig_logo.gif Robert Creager, Principal Software Engineer Oracle Server Technologies 500 Eldorado Blvd, Bldg 5 Broomfield, CO, 80021 Phone: 303-272-6830 Email: robert.crea...@oracle.com inline: green-for-email-sig_0.gifOracle is committed to developing practices and products that help protect the environment -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Why polecat and colugos are failing to build back branches
On Jun 13, 2011, at 6:05 PM, Tom Lane t...@sss.pgh.pa.us wrote: I looked into $SUBJECT. There appear to be two distinct issues: 1. On colugos (OS X with LLVM), the ... However, because when using gcc that only results in a warning, we didn't back-patch it. Now it appears that it's an error when using LLVM, so maybe we oughta back-patch it, at least to whichever releases we think will build with LLVM. FYI, in the latest beta developer XCode release, gcc is llvm. That's not my test machine though. 2. Pre-9.0, the installation step is failing like this: ... alternatives seem to be to ask Robert to rename the volume, or stop testing pre-9.0 branches on that machine. Any change is no problem, just let me know. Later, Rob -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Polecat quit unexpectdly
9600M GT, NVIDIA GeForce 9600M GT, PCIe, 512 MBGraphics: NVIDIA GeForce 9400M, NVIDIA GeForce 9400M, PCI, 256 MBMemory Module: global_nameAirPort: spairport_wireless_card_type_airport_extreme (0x14E4, 0x8D), Broadcom BCM43xx 1.0 (5.10.131.36.9)Bluetooth: Version 2.4.0f1, 2 service, 19 devices, 1 incoming serial portsNetwork Service: Ethernet, Ethernet, en0Network Service: AirPort, AirPort, en1Network Service: Parallels Shared Networking Adapter, Ethernet, en3Network Service: Parallels Host-Only Networking Adapter, Ethernet, en4Serial ATA Device: OWC Mercury Extreme Pro SSD, 223.57 GBSerial ATA Device: MATSHITADVD-R UJ-868USB Device: Hub, 0x0409 (NEC Corporation), 0x005a, 0x2410USB Device: Hub, 0x0409 (NEC Corporation), 0x005a, 0x2414USB Device: Hub, 0x0409 (NEC Corporation), 0x005a, 0x24142000USB Device: TOSHIBA Video Dock, 0x17e9 (DisplayLink (UK) Ltd.), 0x0110, 0x24142100USB Device: USB Sound Device, 0x0d8c (C-MEDIA ELECTRONICS INC.), 0x0102, 0x24142300USB Device: Hub, 0x0409 (NEC Corporation), 0x005a, 0x24142400USB Device: Keyboard Hub, 0x05ac (Apple Inc.), 0x1006, 0x24142420USB Device: Apple Keyboard, 0x05ac (Apple Inc.), 0x0220, 0x24142422USB Device: Hub, 0x0424 (SMSC), 0x2514, 0x24142410USB Device: My Passport 070A, 0x1058 (Western Digital Technologies, Inc.), 0x070a, 0x24142440USB Device: AX88772, 0x0b95 (ASIX Electronics Corporation), 0x7720, 0x24142200USB Device: OWC Express USB3.0, 0x0dc4 (Macpower Tytech Technology Co., LTD.), 0x020a, 0x24144000USB Device: ST94811U2-RK, 0x0bc2, 0x0502, 0x24143000USB Device: Built-in iSight, 0x05ac (Apple Inc.), 0x8507, 0x2440USB Device: BRCM2046 Hub, 0x0a5c (Broadcom Corp.), 0x4500, 0x0610USB Device: Bluetooth USB Host Controller, 0x05ac (Apple Inc.), 0x8213, 0x0611USB Device: Apple Internal Keyboard / Trackpad, 0x05ac (Apple Inc.), 0x0236, 0x0460USB Device: IR Receiver, 0x05ac (Apple Inc.), 0x8242, 0x0450 --Robert Creager, Principal Software EngineerOracleServer Technologies500 Eldorado Blvd, Bldg 5Broomfield, CO, 80021Phone: 303-272-6830Email: robert.crea...@oracle.comOracle is committed to developing practices and products that help protect the environment
Re: [HACKERS] Why polecat and colugos are failing to build back branches
On Jun 14, 2011, at 3:45 PM, Tom Lane t...@sss.pgh.pa.us wrote: I've committed patches that fix these issues on my own OS X machine, though it remains to be seen whether polecat and colugos will like them. It turns out that whatever setup Robert has got with '/Volumes/High Usage/' is really *not* fully exercising the system as far as space-containing paths go, because I found bugs in all '/Volumes/High Usage' is a new external drive as I put in a SSD as the main drive. Rather than re-do all my configs, I created a symbolic link from /usr/local/src/pg_buildfarm... to the external disk. active branches when I tried to do builds and installs underneath '/Users/tgl/foo bar/'. Is it worth setting up a buildfarm critter to exercise the case on a long-term basis? If we don't, I think we can expect that it'll break regularly. I'd be happy to do that on my iMac, which isn't a build farm member yet, although I had plans to add it. I can easily do a single tester with spaces in the path, or multiple testers with and without spaces. I'll work on the build farm config setup at least for the space scenario. Cheers, Rob -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [Pgbuildfarm-members] CREATE FUNCTION hang on test machine polecat on HEAD
On Jun 8, 2011, at 9:13 AM, Robert Creager wrote:I've renamed /opt/local so it's not picked up, and change HEAD to build every 6 hours. Won't prove it doesn't happen though... If it appears to work for a bit, I can move /opt/local back and see what happens.Gack. ccache is in /opt/local/bin... I've reverted for now, keep the 6 hour force build, and will re-work my config and put ccache somewhere else.Sigh,Rob --Robert Creager, Principal Software EngineerOracleServer Technologies500 Eldorado Blvd, Bldg 5Broomfield, CO, 80021Phone: 303-272-6830Email: robert.crea...@oracle.comOracle is committed to developing practices and products that help protect the environment
Re: [HACKERS] [Pgbuildfarm-members] CREATE FUNCTION hang on test machine polecat on HEAD
On Jun 7, 2011, at 11:32 PM, Tom Lane t...@sss.pgh.pa.us wrote: But I tried make installcheck in plperl quite a few times with no problems. (And yes, I tried some assorted settings of PERL_HASH_SEED, as well as none at all.) At this point I'm thinking that the perl you've got in /opt/local must be bollixing the works somehow, though it's not clear how. It's also really strange that it evidently only fails some of the time ... I've renamed /opt/local so it's not picked up, and change HEAD to build every 6 hours. Won't prove it doesn't happen though... If it appears to work for a bit, I can move /opt/local back and see what happens. I'll see about setting up my iMac at home for the build farm for another Apple machine. Anything you'd like to change, or run, or something else? Later, Rob
Re: [HACKERS] [Pgbuildfarm-members] CREATE FUNCTION hang on test machine polecat on HEAD
On Jun 7, 2011, at 12:42 PM, Alex Hunsaker bada...@gmail.com wrote: On Tue, Jun 7, 2011 at 12:22, Tom Lane t...@sss.pgh.pa.us wrote: Alex Hunsaker bada...@gmail.com writes: Im looking at the raw perl 5.10.0 source... I wonder if apple is shipping a modified version? You could find out by digging around at http://www.opensource.apple.com/ polecat appears to be running OSX 10.6.7, so this is what you want: http://www.opensource.apple.com/tarballs/perl/perl-63.tar.gz Thanks! Another question worth asking here is whether PG is picking up perl 5.10.0 or 5.8.9, both of which are shipped in this OSX release. I was looking at http://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=polecatdt=2011-06-07%2015%3A23%3A34stg=config which seems to point at 5.10.0. Robert: perl -V might be useful Hmm... This might be a problem: which perl /opt/local/bin/perl type -a perl /opt/local/bin/perl /usr/bin/perl /opt/local/bin/perl -V This is perl, v5.8.9 built for darwin-2level Copyright 1987-2008, Larry Wall Perl may be copied only under the terms of either the Artistic License or the GNU General Public License, which may be found in the Perl 5 source kit. Complete documentation for Perl, including FAQ lists, should be found on this system using man perl or perldoc perl. If you have access to the Internet, point your browser at http://www.perl.org/, the Perl Home Page. /usr/bin/perl -V Summary of my perl5 (revision 5 version 10 subversion 0) configuration: Platform: osname=darwin, osvers=10.0, archname=darwin-thread-multi-2level uname='darwin neige.apple.com 10.0 darwin kernel version 10.0.0d8: tue may 5 19:29:59 pdt 2009; root:xnu-1437.2~2release_i386 i386 ' config_args='-ds -e -Dprefix=/usr -Dccflags=-g -pipe -Dldflags= -Dman3ext=3pm -Duseithreads -Duseshrplib -Dinc_version_list=none -Dcc=gcc-4.2' hint=recommended, useposix=true, d_sigaction=define useithreads=define, usemultiplicity=define useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef use64bitint=define, use64bitall=define, uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='gcc-4.2', ccflags ='-arch x86_64 -arch i386 -arch ppc -g -pipe -fno-common -DPERL_DARWIN -fno-strict-aliasing -I/usr/local/include', optimize='-Os', cppflags='-g -pipe -fno-common -DPERL_DARWIN -fno-strict-aliasing -I/usr/local/include' ccversion='', gccversion='4.2.1 (Apple Inc. build 5646)', gccosandvers='' intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=12345678 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16 ivtype='long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=8, prototype=define Linker and Libraries: ld='gcc-4.2 -mmacosx-version-min=10.6', ldflags ='-arch x86_64 -arch i386 -arch ppc -L/usr/local/lib' libpth=/usr/local/lib /usr/lib libs=-ldbm -ldl -lm -lutil -lc perllibs=-ldl -lm -lutil -lc libc=/usr/lib/libc.dylib, so=dylib, useshrplib=true, libperl=libperl.dylib gnulibc_version='' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=bundle, d_dlsymun=undef, ccdlflags=' ' cccdlflags=' ', lddlflags='-arch x86_64 -arch i386 -arch ppc -bundle -undefined dynamic_lookup -L/usr/local/lib' Characteristics of this binary (from libperl): Compile-time options: MULTIPLICITY PERL_DONT_CREATE_GVSV PERL_IMPLICIT_CONTEXT PERL_MALLOC_WRAP USE_64_BIT_ALL USE_64_BIT_INT USE_ITHREADS USE_LARGE_FILES USE_PERLIO USE_REENTRANT_API Locally applied patches: /Library/Perl/Updates/version comes before system perl directories installprivlib and installarchlib points to the Updates directory Built under darwin Compiled at Jun 24 2009 00:35:27 @INC: /Library/Perl/Updates/5.10.0/darwin-thread-multi-2level /Library/Perl/Updates/5.10.0 /System/Library/Perl/5.10.0/darwin-thread-multi-2level /System/Library/Perl/5.10.0 /Library/Perl/5.10.0/darwin-thread-multi-2level /Library/Perl/5.10.0 /Network/Library/Perl/5.10.0/darwin-thread-multi-2level /Network/Library/Perl/5.10.0 /Network/Library/Perl /System/Library/Perl/Extras/5.10.0/darwin-thread-multi-2level /System/Library/Perl/Extras/5.10.0 .
Re: [HACKERS] [Pgbuildfarm-members] CREATE FUNCTION hang on test machine polecat on HEAD
On Jun 7, 2011, at 3:01 PM, Tom Lane wrote: Robert Creager robert.crea...@oracle.com writes: The configure log mentioned upthread says it's finding /usr/bin/perl, so apparently the buildfarm is running with a different PATH than you're using here. But that log also shows configure:7158: checking for flags to link embedded Perl configure:7174: result: -L/usr/local/lib -L/System/Library/Perl/5.10.0/darwin-thread-multi-2level/CORE -lperl -ldl -lm -lutil -lc If there's anything perl-related in /usr/local/lib (not /opt/local/lib), that could be confusing matters. That's what I get for doing this in a meeting, doing both poorly. run_build.pl: #!/usr/bin/perl No perl in /usr/local/lib. Rob -- inline: oracle_sig_logo.gif Robert Creager, Principal Software Engineer Oracle Server Technologies 500 Eldorado Blvd, Bldg 5 Broomfield, CO, 80021 Phone: 303-272-6830 Email: robert.crea...@oracle.com inline: green-for-email-sig_0.gifOracle is committed to developing practices and products that help protect the environment -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [Pgbuildfarm-members] CREATE FUNCTION hang on test machine polecat on HEAD
On Jun 6, 2011, at 7:29 PM, Andrew Dunstan and...@dunslane.net wrote: On 06/06/2011 07:30 PM, Robert Creager wrote: [4de65a8f.607a:1] LOG: connection received: host=[local] [4de65a8f.607a:2] LOG: connection authorized: user=Robert database=pl_regression [4de65a8f.607a:3] LOG: statement: CREATE OR REPLACE FUNCTION bar() RETURNS integer AS $$ #die 'BANG!'; # causes server process to exit(2) # alternative - causes server process to exit(255) spi_exec_query(invalid sql statement); $$ language plperl; I'll leave it running tonight (going home), so I can poke tomorrow if anyone wants me to. That's weird. Why it should hang there I have no idea. Did it hang at the same spot both times? Can you get a backtrace? I think so, but I didn't pay much attention :-( GNU gdb 6.3.50-20050815 (Apple version gdb-1518) (Sat Feb 12 02:52:12 UTC 2011) Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as x86_64-apple-darwin...Reading symbols for shared libraries .. done Attaching to program: `/Volumes/High Usage/usr/local/src/build-farm-4.4/builds/HEAD/inst/bin/postgres', process 24698. Reading symbols for shared libraries .+. done 0x000100a505e4 in Perl_get_hash_seed () (gdb) bt #0 0x000100a505e4 in Perl_get_hash_seed () #1 0x000100a69b94 in perl_parse () #2 0x0001007bb680 in plperl_init_interp () at plperl.c:781 #3 0x0001007bc17a in _PG_init () at plperl.c:443 #4 0x000100301da6 in internal_load_library (libname=0x10100d540 /Volumes/High Usage/usr/local/src/build-farm-4.4/builds/HEAD/inst/lib/postgresql/plperl.so) at dfmgr.c:284 #5 0x0001003026f5 in load_external_function (filename=value temporarily unavailable, due to optimizations, funcname=0x10100d508 plperl_validator, signalNotFound=1 '\001', filehandle=0x7fff5fbfd3b8) at dfmgr.c:113 #6 0x000100304c10 in fmgr_info_C_lang [inlined] () at /Volumes/High Usage/usr/local/src/build-farm-4.4/builds/HEAD/pgsql.2569/src/backend/utils/fmgr/fmgr.c:349 #7 0x000100304c10 in fmgr_info_cxt_security (functionId=41321, finfo=0x7fff5fbfd410, mcxt=value temporarily unavailable, due to optimizations, ignore_security=value temporarily unavailable, due to optimizations) at fmgr.c:280 #8 0x000100305e00 in OidFunctionCall1Coll (functionId=value temporarily unavailable, due to optimizations, collation=0, arg1=41426) at fmgr.c:1585 #9 0x00010009e493 in ProcedureCreate (procedureName=0x101006550 bar, procNamespace=2200, replace=1 '\001', returnsSet=0 '\0', returnType=23, languageObjectId=41322, languageValidator=41321, prosrc=0x101006748 \n#die 'BANG!'; # causes server process to exit(2)\n# alternative - causes server process to exit(255)\nspi_exec_query(\invalid sql statement\);\n, probin=0x0, isAgg=0 '\0', isWindowFunc=0 '\0', security_definer=0 '\0', isStrict=0 '\0', volatility=118 'v', parameterTypes=0x10100d7d8, allParameterTypes=0, parameterModes=0, parameterNames=0, parameterDefaults=0x0, proconfig=0, procost=100, prorows=0) at pg_proc.c:652 #10 0x0001001046be in CreateFunction (stmt=0x101006a48, queryString=0x101005a38 CREATE OR REPLACE FUNCTION bar() RETURNS integer AS $$\n#die 'BANG!'; # causes server process to exit(2)\n# alternative - causes server process to exit(255)\nspi_exec_query(\invalid sql state...) at functioncmds.c:942 #11 0x00010023633b in MemoryContextSwitchTo [inlined] () at /Volumes/High Usage/usr/local/src/build-farm-4.4/builds/HEAD/pgsql.2569/src/include/utils/palloc.h:1184 #12 0x00010023633b in PortalRunUtility (portal=0x101027238, utilityStmt=0x101006a48, isTopLevel=value temporarily unavailable, due to optimizations, dest=0x101006df0, completionTag=0x7fff5fbfdea0 ) at pquery.c:1192 #13 0x000100237af5 in PortalRunMulti (portal=0x101027238, isTopLevel=value temporarily unavailable, due to optimizations, dest=0x101006df0, altdest=0x101006df0, completionTag=0x7fff5fbfdea0 ) at pquery.c:1315 #14 0x0001002384a8 in PortalRun (portal=0x101027238, count=9223372036854775807, isTopLevel=value temporarily unavailable, due to optimizations, dest=0x101006df0, altdest=0x101006df0, completionTag=0x7fff5fbfdea0 ) at pquery.c:813 #15 0x00010023445d in exec_simple_query (query_string=0x101005a38 CREATE OR REPLACE FUNCTION bar() RETURNS integer AS $$\n#die 'BANG!'; # causes server process to exit(2)\n# alternative - causes server process to exit(255)\nspi_exec_query(\invalid sql state...) at postgres.c:1018 #16 0x000100235021 in PostgresMain (argc=2, argv=value temporarily unavailable, due to optimizations, username=value temporarily unavailable, due to optimizations
[HACKERS] CREATE FUNCTION hang on test machine polecat on HEAD
g = shift; my $result = "";for my $row_ref (@$array_arg) { die "not a hash reference" unless (ref $row_ref eq "HASH");$result .= $row_ref-{bar}." items of ".$row_ref-{baz}.";"; } return $result .' '. $array_arg; $$ LANGUAGE plperl;[4de65a8f.6076:21] LOG: statement: select plperl_array_of_rows(ARRAY[ ROW(2, 'coffee'), ROW(0, 'sugar')]::foo[]);[4de65a8f.6076:22] LOG: statement: CREATE TYPE rowfoo AS (bar INTEGER, baz INTEGER[]);[4de65a8f.6076:23] LOG: statement: CREATE OR REPLACE FUNCTION plperl_sum_row_elements(rowfoo) RETURNS TEXT AS $$ my $row_ref = shift; my $result;if (ref $row_ref ne 'HASH') { $result = 0; } else { $result = $row_ref-{bar}; die "not an array reference".ref ($row_ref-{baz}) unless (is_array_ref($row_ref-{baz})); # process a single-dimensional array foreach my $elem (@{$row_ref-{baz}}) {$result += $elem unless ref $elem; } } return $result; $$ LANGUAGE plperl;[4de65a8f.6076:24] LOG: statement: select plperl_sum_row_elements(ROW(1, ARRAY[2,3,4,5,6,7,8,9,10])::rowfoo);[4de65a8f.6076:25] LOG: statement: CREATE TYPE rowbar AS (foo rowfoo[]);[4de65a8f.6076:26] LOG: statement: CREATE OR REPLACE FUNCTION plperl_sum_array_of_rows(rowbar) RETURNS TEXT AS $$ my $rowfoo_ref = shift; my $result = 0;if (ref $rowfoo_ref eq 'HASH') { my $row_array_ref = $rowfoo_ref-{foo}; if (is_array_ref($row_array_ref)) {foreach my $row_ref (@{$row_array_ref}) { if (ref $row_ref eq 'HASH') { $result += $row_ref-{bar}; die "not an array reference".ref ($row_ref-{baz}) unless (is_array_ref($row_ref-{baz})); foreach my $elem (@{$row_ref-{baz}}) { $result += $elem unless ref $elem; } } else { die "element baz is not a reference to a rowfoo"; }} } else {die "not a reference to an array of rowfoo elements" } } else { die "not a reference to type rowbar"; } return $result; $$ LANGUAGE plperl;[4de65a8f.6076:27] LOG: statement: select plperl_sum_array_of_rows(ROW(ARRAY[ROW(1, ARRAY[2,3,4,5,6,7,8,9,10])::rowfoo, ROW(11, ARRAY[12,13,14,15,16,17,18,19,20])::rowfoo])::rowbar);[4de65a8f.6076:28] LOG: statement: CREATE OR REPLACE FUNCTION plperl_arrays_out(OUT INTEGER[]) AS $$ return [[1,2,3],[4,5,6]]; $$ LANGUAGE plperl;[4de65a8f.6076:29] LOG: statement: select plperl_arrays_out();[4de65a8f.6076:30] LOG: statement: CREATE OR REPLACE FUNCTION plperl_arrays_inout(INTEGER[]) returns INTEGER[] AS $$ return shift; $$ LANGUAGE plperl;[4de65a8f.6076:31] LOG: statement: select plperl_arrays_inout('{{1}, {2}, {3}}');[4de65a8f.6076:32] LOG: statement: create or replace function perl_setof_array(integer[]) returns setof integer[] language plperl as $$ my $arr = shift; for my $r (@$arr) { return_next $r; } return undef; $$;[4de65a8f.6076:33] LOG: statement: select perl_setof_array('{{1}, {2}, {3}}');[4de65a8f.6076:34] LOG: disconnection: session time: 0:00:00.076 user=Robert database=pl_regression host=[local][4de65a8f.607a:1] LOG: connection received: host=[local][4de65a8f.607a:2] LOG: connection authorized: user=Robert database=pl_regression[4de65a8f.607a:3] LOG: statement: CREATE OR REPLACE FUNCTION bar() RETURNS integer AS $$ #die 'BANG!'; # causes server process to exit(2) # alternative - causes server process to exit(255) spi_exec_query("invalid sql statement"); $$ language plperl;I'll leave it running tonight (going home), so I can poke tomorrow if anyone wants me to.Later,Rob
--Robert Creager, Principal Software EngineerOracleServer Technologies500 Eldorado Blvd, Bldg 5Broomfield, CO, 80021Phone: 303-272-6830Email: robert.crea...@oracle.comOracle is committed to developing practices and products that help protect the environment
[HACKERS] Fwd: PGBuildfarm member polecat Branch HEAD Status changed from StartDb-C:2 failure to StartDb-C:3 failure
And another one (different compiler): Process: postgres [48669] Path:/usr/local/src/build-farm-3.2/builds/HEAD/inst/bin/postgres Identifier: postgres Version: ??? (???) Code Type: X86-64 (Native) Parent Process: postgres [48015] Date/Time: 2010-05-19 18:06:37.908 -0600 OS Version: Mac OS X 10.6.3 (10D573) Report Version: 6 Interval Since Last Report: 397326 sec Crashes Since Last Report: 11 Per-App Crashes Since Last Report: 3 Anonymous UUID: 77053C10-A2B5-4078-A796-5862E233A1AC Exception Type: EXC_CRASH (SIGABRT) Exception Codes: 0x, 0x Crashed Thread: 0 Dispatch queue: com.apple.main-thread Application Specific Information: abort() called Thread 0 Crashed: Dispatch queue: com.apple.main-thread 0 libSystem.B.dylib 0x7fff88268886 __kill + 10 1 libSystem.B.dylib 0x7fff88308eae abort + 83 2 postgres0x00010039f998 errfinish + 882 3 postgres0x000100066ec2 UpdateControlFile + 286 4 postgres0x00010006bd67 CreateCheckPoint + 409 5 postgres0x00010006b779 ShutdownXLOG + 154 6 postgres0x000100244999 BackgroundWriterMain + 1022 7 postgres0x000100098fe8 AuxiliaryProcessMain + 1864 8 postgres0x00010025240a StartChildProcess + 285 9 postgres0x00010024ff0e reaper + 402 10 libSystem.B.dylib 0x7fff8827a80a _sigtramp + 26 11 libSystem.B.dylib 0x7fff8825e286 select$DARWIN_EXTSN + 10 12 postgres0x00010024e46a ServerLoop + 164 13 postgres0x00010024dc83 PostmasterMain + 4203 14 postgres0x0001001c73f8 main + 556 15 postgres0x00011324 start + 52 Thread 0 crashed with X86 Thread State (64-bit): rax: 0x rbx: 0x rcx: 0x7fff5fbfeab8 rdx: 0x rdi: 0xbe1d rsi: 0x0006 rbp: 0x7fff5fbfead0 rsp: 0x7fff5fbfeab8 r8: 0x000101002890 r9: 0x7fff5fbfe970 r10: 0x7fff882648ca r11: 0x0202 r12: 0x r13: 0x r14: 0x r15: 0x rip: 0x7fff88268886 rfl: 0x0202 cr2: 0x52df4556 Binary Images: 0x1 -0x1005aafe7 +postgres ??? (???) FC69B957-D4BB-B3B0-1880-21EEE14A3AF9 /usr/local/src/build-farm-3.2/builds/HEAD/inst/bin/postgres 0x1007c8000 -0x1008e9fff +libxml2.2.dylib 10.7.0 (compatibility 10.0.0) CC8AA05E-419A-8855-CA51-3E988F6AF074 /opt/local/lib/libxml2.2.dylib 0x10091a000 -0x10095bfef +libssl.0.9.8.dylib 0.9.8 (compatibility 0.9.8) E95CC9C8-7EA2-49DC-8ADB-38ABB54ADCD4 /opt/local/lib/libssl.0.9.8.dylib 0x10096f000 -0x100a81ff7 +libcrypto.0.9.8.dylib 0.9.8 (compatibility 0.9.8) 869559F9-EF7E-94F5-6810-2D4B9163F7A0 /opt/local/lib/libcrypto.0.9.8.dylib 0x100ae4000 -0x100af8ff7 +libz.1.dylib 1.2.5 (compatibility 1.0.0) CED4D01F-2054-94F0-E944-962F279BC84C /opt/local/lib/libz.1.dylib 0x100afc000 -0x100bf8ff7 +libiconv.2.dylib 8.0.0 (compatibility 8.0.0) D674866F-82E0-B1ED-4A97-9B8ED4EE6C3B /opt/local/lib/libiconv.2.dylib 0x7fff5fc0 - 0x7fff5fc3bdef dyld 132.1 (???) B633F790-4DDB-53CD-7ACF-2A3682BCEA9F /usr/lib/dyld 0x7fff803aa000 - 0x7fff803abff7 com.apple.TrustEvaluationAgent 1.1 (1) 51867586-1C71-AE37-EAAD-535A58DD3550 /System/Library/PrivateFrameworks/TrustEvaluationAgent.framework/Versions/A/TrustEvaluationAgent 0x7fff81525000 - 0x7fff81537fe7 libsasl2.2.dylib 3.15.0 (compatibility 3.0.0) 76B83C8D-8EFE-4467-0F75-275648AFED97 /usr/lib/libsasl2.2.dylib 0x7fff81865000 - 0x7fff8189dff7 libssl.0.9.8.dylib 0.9.8 (compatibility 0.9.8) FAB9687F-0A86-A13F-7644-CE02E71140DB /usr/lib/libssl.0.9.8.dylib 0x7fff82491000 - 0x7fff82495ff7 libmathCommon.A.dylib 315.0.0 (compatibility 1.0.0) 95718673-FEEE-B6ED-B127-BCDBDB60D4E5 /usr/lib/system/libmathCommon.A.dylib 0x7fff8491e000 - 0x7fff84a2dfe7 libcrypto.0.9.8.dylib 0.9.8 (compatibility 0.9.8) 826C2437-F760-E049-1719-9C69A3BAA4B0 /usr/lib/libcrypto.0.9.8.dylib 0x7fff8549d000 - 0x7fff854befff libresolv.9.dylib 40.0.0 (compatibility 1.0.0) 1AE68BBB-6536-125C-DE2A-13CA916D0EC4 /usr/lib/libresolv.9.dylib 0x7fff86bad000 - 0x7fff86beafff com.apple.LDAPFramework 2.0 (120.1) 16383FF5-0537-6298-73C9-473AEC9C149C /System/Library/Frameworks/LDAP.framework/Versions/A/LDAP 0x7fff86e61000 - 0x7fff86e72ff7 libz.1.dylib 1.2.3 (compatibility 1.0.0) C1154E2E-B1CB-1FAD-77ED-B139BA1AB073
[HACKERS] Fwd: PGBuildfarm member colugos Branch HEAD Status changed from OK to StartDb-C:3 failure
If anyone is interested, I think this failure was accompanied by the following: Process: postgres [35159] Path: /usr/local/src/build-farm-3.2_llvm/builds/HEAD/inst/bin/postgres Identifier: postgres Version: ??? (???) Code Type: X86-64 (Native) Parent Process: postgres [35036] Date/Time: 2010-05-19 17:12:19.213 -0600 OS Version: Mac OS X 10.6.3 (10D573) Report Version: 6 Interval Since Last Report: 394069 sec Crashes Since Last Report: 10 Per-App Crashes Since Last Report: 2 Anonymous UUID: 77053C10-A2B5-4078-A796-5862E233A1AC Exception Type: EXC_CRASH (SIGABRT) Exception Codes: 0x, 0x Crashed Thread: 0 Dispatch queue: com.apple.main-thread Application Specific Information: abort() called Thread 0 Crashed: Dispatch queue: com.apple.main-thread 0 libSystem.B.dylib 0x7fff88268886 __kill + 10 1 libSystem.B.dylib 0x7fff88308eae abort + 83 2 postgres0x0001004cd513 errfinish + 1059 3 postgres0x00010008ae1e UpdateControlFile + 382 4 postgres0x000100091f93 CreateCheckPoint + 659 5 postgres0x0001000917c1 ShutdownXLOG + 193 6 postgres0x0001002fa042 BackgroundWriterMain + 1378 7 postgres0x0001000d0139 AuxiliaryProcessMain + 1993 8 postgres0x00010030c924 StartChildProcess + 356 9 postgres0x000100309ab9 reaper + 489 10 libSystem.B.dylib 0x7fff8827a80a _sigtramp + 26 11 libSystem.B.dylib 0x7fff8825e286 select$DARWIN_EXTSN + 10 12 postgres0x0001003076cc ServerLoop + 364 13 postgres0x000100306a04 PostmasterMain + 5588 14 postgres0x00010025cd0b main + 667 15 postgres0x00010da4 start + 52 Thread 0 crashed with X86 Thread State (64-bit): rax: 0x rbx: 0x7fff5fbff0e0 rcx: 0x7fff5fbfe548 rdx: 0x rdi: 0x8957 rsi: 0x0006 rbp: 0x7fff5fbfe560 rsp: 0x7fff5fbfe548 r8: 0x000101002890 r9: 0x7fff5fbfe438 r10: 0x7fff882648ca r11: 0x0202 r12: 0x r13: 0x r14: 0x r15: 0x rip: 0x7fff88268886 rfl: 0x0202 cr2: 0x000100536050 Binary Images: 0x1 -0x1006eafef +postgres ??? (???) 20ED8627-555A-780D-6CD7-B7AACBD814EC /usr/local/src/build-farm-3.2_llvm/builds/HEAD/inst/bin/postgres 0x100917000 -0x100a38fff +libxml2.2.dylib 10.7.0 (compatibility 10.0.0) CC8AA05E-419A-8855-CA51-3E988F6AF074 /opt/local/lib/libxml2.2.dylib 0x100a69000 -0x100aaafef +libssl.0.9.8.dylib 0.9.8 (compatibility 0.9.8) E95CC9C8-7EA2-49DC-8ADB-38ABB54ADCD4 /opt/local/lib/libssl.0.9.8.dylib 0x100abe000 -0x100bd0ff7 +libcrypto.0.9.8.dylib 0.9.8 (compatibility 0.9.8) 869559F9-EF7E-94F5-6810-2D4B9163F7A0 /opt/local/lib/libcrypto.0.9.8.dylib 0x100c33000 -0x100c47ff7 +libz.1.dylib 1.2.5 (compatibility 1.0.0) CED4D01F-2054-94F0-E944-962F279BC84C /opt/local/lib/libz.1.dylib 0x100c4b000 -0x100d47ff7 +libiconv.2.dylib 8.0.0 (compatibility 8.0.0) D674866F-82E0-B1ED-4A97-9B8ED4EE6C3B /opt/local/lib/libiconv.2.dylib 0x7fff5fc0 - 0x7fff5fc3bdef dyld 132.1 (???) B633F790-4DDB-53CD-7ACF-2A3682BCEA9F /usr/lib/dyld 0x7fff803aa000 - 0x7fff803abff7 com.apple.TrustEvaluationAgent 1.1 (1) 51867586-1C71-AE37-EAAD-535A58DD3550 /System/Library/PrivateFrameworks/TrustEvaluationAgent.framework/Versions/A/TrustEvaluationAgent 0x7fff81525000 - 0x7fff81537fe7 libsasl2.2.dylib 3.15.0 (compatibility 3.0.0) 76B83C8D-8EFE-4467-0F75-275648AFED97 /usr/lib/libsasl2.2.dylib 0x7fff81865000 - 0x7fff8189dff7 libssl.0.9.8.dylib 0.9.8 (compatibility 0.9.8) FAB9687F-0A86-A13F-7644-CE02E71140DB /usr/lib/libssl.0.9.8.dylib 0x7fff82491000 - 0x7fff82495ff7 libmathCommon.A.dylib 315.0.0 (compatibility 1.0.0) 95718673-FEEE-B6ED-B127-BCDBDB60D4E5 /usr/lib/system/libmathCommon.A.dylib 0x7fff8491e000 - 0x7fff84a2dfe7 libcrypto.0.9.8.dylib 0.9.8 (compatibility 0.9.8) 826C2437-F760-E049-1719-9C69A3BAA4B0 /usr/lib/libcrypto.0.9.8.dylib 0x7fff8549d000 - 0x7fff854befff libresolv.9.dylib 40.0.0 (compatibility 1.0.0) 1AE68BBB-6536-125C-DE2A-13CA916D0EC4 /usr/lib/libresolv.9.dylib 0x7fff86bad000 - 0x7fff86beafff com.apple.LDAPFramework 2.0 (120.1) 16383FF5-0537-6298-73C9-473AEC9C149C /System/Library/Frameworks/LDAP.framework/Versions/A/LDAP 0x7fff86e61000 - 0x7fff86e72ff7 libz.1.dylib 1.2.3
Re: [HACKERS] Fwd: PGBuildfarm member colugos Branch HEAD Status changed from OK to StartDb-C:3 failure
On May 20, 2010, at 11:54 AM, Tom Lane wrote: Robert Creager r...@logicalchaos.org writes: If anyone is interested, I think this failure was accompanied by the following: [ apparent PANIC in UpdateControlFile ] Hmm, do you have the panic message in the postmaster log? So far as I can tell, the postmaster log isn't captured anywhere in the buildfarm report of this event. (Which seems like a buildfarm bug.) 'Course not. Given that polecat has already run a couple of later buildfarm iterations, I'm not too hopeful that you do have that log file. Was there any special environment here, like running out of disk space? Not that I'm aware of. I did empty trash sometime yesterday after noticing I was around 1Gb of free disk. Not sure if that correlates or not. Maybe on failure buildfarm should could disk usage of the disk it's on and add that to the report? I've updated my OSX clients to keep error builds. Later, Rob -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] buildfarm logging versus embedded nulls
On Mar 11, 2010, at 6:00 PM, Andrew Dunstan wrote: Tom Lane wrote: I was looking at this recent nonrepeatable buildfarm failure: http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=polecatdt=2010-03-11%2021:45:10 which has several instances of the known pgstat wait timeout problem during the parallel regression tests. You've got me trained well now. I'm now looking at my build machine failures. Wasn't sure what to do about that one, since no relevant files changed. Is there any value in setting keep_error_builds = 0,? I know Andrew was able to get the complete log file. Cheers, Rob -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] happy birthday Tom Lane ...
On Sep 18, 2009, at 5:18 PM, Paul Matthews wrote: happy_birthday++; SELECT count( happy ) FROM birthday WHERE name ~ 'Tom Lane'; WARNING : condition stack overflow: INF Sigh, Rob smime.p7s Description: S/MIME cryptographic signature
Re: [HACKERS] drop tablespace error: invalid argument
On Sep 11, 2009, at 2:35 PM, David E. Wheeler wrote: On Sep 11, 2009, at 12:42 PM, Tom Lane wrote: Well, 10.6.1 is out and it's still got the readdir() bug :-(. Has someone filed a bug report about this with Apple? https://bugreport.apple.com/cgi-bin/WebObjects/RadarWeb.woa If no one has (yet), I'll be happy to. I just submitted one for an AirPort problem... I guess I'll whip up an example program and just submit it anyway... Anyone already written one? Later, Rob smime.p7s Description: S/MIME cryptographic signature
Re: [HACKERS] drop tablespace error: invalid argument
On Sep 11, 2009, at 2:35 PM, David E. Wheeler wrote: On Sep 11, 2009, at 12:42 PM, Tom Lane wrote: Well, 10.6.1 is out and it's still got the readdir() bug :-(. Has someone filed a bug report about this with Apple? https://bugreport.apple.com/cgi-bin/WebObjects/RadarWeb.woa Look at the history of this thread, and it's already submitted: http://www.nabble.com/drop-tablespace-error:-invalid-argument-td24992634.html Later, Rob smime.p7s Description: S/MIME cryptographic signature
[HACKERS] Any interest in buildfarm a member using Apple's llvm-gcc-4.2 or clang?
I'll set up one or two more 'machines' if there is interest (Snow Leopard) % /Developer/usr/bin/llvm-gcc-4.2 --version i686-apple-darwin10-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5646) (LLVM build 2118) llvm-gcc-4.2 currently fails during check for the known directory problem under Snow Leopard as the regular gcc does. I tried HEAD, REL8_4_STABLE and REL8_3_STABLE. % /Developer/usr/bin/clang --version clang version 1.0 (http://llvm.org/svn/llvm-project/cfe/tags/Apple/clang-23 exported ) clang fails to compile on HEAD, so I did no more checking on it. clang: warning: argument unused during compilation: '-no-cpp-precomp' clang: warning: argument unused during compilation: '-fwrapv' clang: warning: argument unused during compilation: '-c' clang: warning: argument unused during compilation: '-no-cpp-precomp' clang: warning: argument unused during compilation: '-I/opt/local/ include' clang: warning: argument unused during compilation: '-fwrapv' clang: warning: argument unused during compilation: '-I.' clang: warning: argument unused during compilation: '-I../../../src/ include' clang: warning: argument unused during compilation: '-I/opt/local/ include/libxml2' In file included from gram.c:1: In file included from gram.y:29784: scan.l:16639:83: error: invalid conversion '%m' [-Wformat] elog_start(scan.l, 978, __func__), elog_finish(20, base_yylex_init() failed: %m); ~~~^~~ 1 diagnostic generated. make[3]: *** [gram.o] Error 1 make[2]: *** [parser-recursive] Error 2 make[1]: *** [all] Error 2 make: *** [all] Error 2 Branch: HEAD Stage Make failed with status 2 Later, Rob smime.p7s Description: S/MIME cryptographic signature
Re: [HACKERS] Any interest in buildfarm a member using Apple's llvm-gcc-4.2 or clang?
On Sep 8, 2009, at 4:18 PM, Tom Lane wrote: Robert Creager rob...@logicalchaos.org writes: I'll set up one or two more 'machines' if there is interest (Snow Leopard) LLVM, perhaps, though are you sure that llvm and gcc aren't the same thing under the hood on SL? I thought I'd read somewhere that Apple had turned gcc into a wrapper around the llvm code generator. Well, the versions reported are definitely different. % gcc --version i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5646) rob...@dhcp-ubrm05-218-133:/usr/local/src/build-farm-3.2_llvm % /Developer/usr/llvm-gcc-4.2/bin/llvm-gcc-4.2 --version i686-apple-darwin10-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5646) (LLVM build 2118) And the llvm tools you only get with the Xcode install, and the sizes of the two gcc compilers are very different. And, the llvm version takes the -flto, where the normal one doesn't: /Developer/usr/llvm-gcc-4.2/bin/llvm-gcc-4.2 -flto main.c -o main_llvm /usr/bin/gcc-4.2 -flto main.c -o main_gcc cc1: error: unrecognized command line option -flto make: *** [main_gcc] Error 1 -flto Enable LLVM Link Time Optimization. And, the binaries are different for the same simple program. So, I'm convinced they are different (where I wasn't sure before). Later, Rob smime.p7s Description: S/MIME cryptographic signature
Re: [HACKERS] [Pgbuildfarm-members] Snow Leopard bison/flex build problem
On Sep 7, 2009, at 11:29 AM, Andrew Dunstan wrote: Robert Creager wrote: Upgraded to Snow Leopard Saturday, and am having problems building now. The build logs are here http://buildfarm.postgresql.org/cgi-bin/show_status.pl?member=polecat And the failing part is here: make -C preproc all make -C ../../../../src/port all make[5]: Nothing to be done for `all'. /usr/bin/perl ./parse.pl . ../../../backend/parser/gram.y preproc.y /usr/bin/bison -d -o preproc.c preproc.y /usr/bin/flex -o'pgc.c' pgc.l /opt/local/bin/ccache gcc -no-cpp-precomp -I/opt/local/include - Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after- statement -Wendif-labels -fno-strict-aliasing -fwrapv -g - DECPG_COMPILE -I../include -I../../../../src/interfaces/ecpg/ include -I. -I. -DMAJOR_VERSION=4 -DMINOR_VERSION=6 -DPATCHLEVEL=0 - I../../../../src/include -I/usr/include/libxml2 -c -o preproc.o preproc.c In file included from preproc.y:12065: pgc.c:161: error: conflicting types for 'yyleng' extern.h:43: error: previous declaration of 'yyleng' was here pgc.c:288: error: conflicting types for 'yyleng' extern.h:43: error: previous declaration of 'yyleng' was here make[4]: *** [preproc.o] Error 1 make[3]: *** [all] Error 2 make[2]: *** [all] Error 2 make[1]: *** [all] Error 2 make: *** [all] Error 2 Please try building by hand and examine the files to find out what the conflict is between these declarations. This is really a -hackers question. pgc.c - 161: extern yy_size_t yyleng; extern.h - 43 : extern int yylineno, yyleng; Thanks, Rob -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [Pgbuildfarm-members] Snow Leopard bison/flex build problem
On Sep 7, 2009, at 1:18 PM, Tom Lane t...@sss.pgh.pa.us wrote: Robert Creager rob...@logicalchaos.org writes: On Sep 7, 2009, at 11:29 AM, Andrew Dunstan wrote: Please try building by hand and examine the files to find out what the conflict is between these declarations. pgc.c - 161: extern yy_size_t yyleng; Bizarre --- my copy of flex 2.5.35 definitely puts out int, and so does everybody else's. Did Apple take it on their own head to change this? regards, tom lane I'll try the macports version, and see what happens. Cheers, Rob Sent from my iPhone -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [Pgbuildfarm-members] Snow Leopard bison/flex build problem
On Sep 7, 2009, at 1:18 PM, Tom Lane wrote: Robert Creager rob...@logicalchaos.org writes: On Sep 7, 2009, at 11:29 AM, Andrew Dunstan wrote: Please try building by hand and examine the files to find out what the conflict is between these declarations. pgc.c - 161: extern yy_size_t yyleng; Bizarre --- my copy of flex 2.5.35 definitely puts out int, and so does everybody else's. Did Apple take it on their own head to change this? Apparently so - the /opt version is from macports. It works. % /opt/local/bin/flex --version flex 2.5.35 % /usr/bin/flex --version flex 2.5.35 Next problems, with HEAD and 8_4, 8_3, 8_2, are here - all with the same error: http://buildfarm.postgresql.org/cgi-bin/show_status.pl?member=polecat ... == running regression test queries== test tablespace ... FAILED ... == pgsql.41144/src/test/regress/regression.diffs === *** /usr/local/src/build-farm-3.2/builds/HEAD/pgsql.41144/src/test/ regress/expected/tablespace.out Mon Sep 7 14:03:30 2009 --- /usr/local/src/build-farm-3.2/builds/HEAD/pgsql.41144/src/test/ regress/results/tablespace.out Mon Sep 7 14:03:43 2009 *** *** 73,75 --- 73,76 drop cascades to table testschema.atable -- Should succeed DROP TABLESPACE testspace; + ERROR: could not read directory pg_tblspc/16388: Invalid argument Sigh, Rob -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [Pgbuildfarm-members] Snow Leopard bison/flex build problem
On Sep 7, 2009, at 2:17 PM, Dave Page wrote: FYI, I've been building from source on Snow Leopard without any problems. If your building from the official tarball, bison/flex are not used. I'm building from CVS, where bison/flex are used. Cheers, rob -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [Pgbuildfarm-members] Snow Leopard bison/flex build problem
On Sep 7, 2009, at 2:41 PM, Dave Page dp...@pgadmin.org wrote: On 9/7/09, Robert Creager rob...@logicalchaos.org wrote: On Sep 7, 2009, at 2:17 PM, Dave Page wrote: FYI, I've been building from source on Snow Leopard without any problems. If your building from the official tarball, bison/flex are not used. I'm building from CVS, where bison/flex are used. Building from CVS, but on closer examination I do have Macports versions of bison/flex ahead of Apple's in the path. Does your make config work? Are you using the 32 or 64 bit kernel? Cheers, Rob Sent from my iPhone -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [Pgbuildfarm-members] Snow Leopard bison/flex build problem
On Sep 7, 2009, at 4:08 PM, Tom Lane t...@sss.pgh.pa.us wrote: Any feelings about that? Should I just hit everything back to 7.4 to be safe? I've noticed on 7.4, Mac gets a spinlock compile error (see polecat logs on buildfarm). Should I give up on the mac for 7.4? Cheers, Rob Sent from my iPhone -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] SIGSEGV taken on 8.1 during dump/reload
I've also modified the Makefile. I removed the special .sql.in : .sql implicit rule and re-organized the Makefile. I didn't commit as it was after 12:00pm when I finished... I'll send you what I did when I return home. If you just replaced the $libdir with $$libdir, then a merge will be easy. Cheers, Rob On Thu, 10 Nov 2005 14:43:30 +0300 Teodor Sigaev [EMAIL PROTECTED] wrote: I fixed path in pg_sphere (and done some more clean up). BTW, I usially install contrib modules before restoring database (of course, it need to dump db without content of modules)... -- Teodor Sigaev E-mail: [EMAIL PROTECTED] WWW: http://www.sigaev.ru/ ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] SIGSEGV taken on 8.1 during dump/reload
When grilled further on (Wed, 09 Nov 2005 10:54:12 +0300), Teodor Sigaev [EMAIL PROTECTED] confessed: So, I'm as sure as I can be right now. How can I check the .so files installed by the build? Do they reference an absolute path for their dependent .so files (postgres), or will they use ld.so.conf, which might then explain the problem. My ld.so.conf still points to the 8.0.2 version, as I've not switched yet to 8.1.0. The simplest way is just remove pg_sphere.so in 8.1 installaion (/usr/local/pgsql810/lib/pg_sphere.so) and try, for example, to create gist index on spoint. Response should be: contrib_regression=# create index test_data_index on test_data using gist( loc ); ERROR: could not access file /usr/local/pgsql/lib/pg_sphere: No such file or directory If not - 8.1 use 8.0 .so Yup. You're right. So, what is happening here? It will be kind of hard to do a live dump/restore on 1 machine if I cannot have two versions running. Is something not set up correctly on my machine, or in the build (pg_sphere or postgresql) that is preventing two copies from... Sigh. Never mind. The dump is spitting out the absolute path for the shared library (like it should): CREATE FUNCTION sbox_in(cstring) RETURNS sbox AS '/usr/local/pgsql802/lib/pg_sphere', 'spherebox_in' LANGUAGE c IMMUTABLE STRICT; Now if I can just figure out how to get this egg off my face... Now I remember the problem I always have, and I have a new trick in my bag: /usr/local/pgsql802/bin/pg_dumpall -c -v | sed 's/pgsql802/pgsql810/' | /usr/local/pgsql810/bin/psql -p 5433 -d template1 How do others handle dumping from one version to a new one? Is there a less error prone way of doing this? As long as I don't have the string pgsql802 anywhere else... Sorry for the bandwidth, Rob -- 07:14:34 up 37 days, 23:49, 6 users, load average: 2.20, 2.17, 2.16 Linux 2.6.5-02 #8 SMP Mon Jul 12 21:34:44 MDT 2004 pgpYYAn0aheg5.pgp Description: PGP signature
Re: [HACKERS] SIGSEGV taken on 8.1 during dump/reload
On Wed, 09 Nov 2005 09:56:51 -0500 Andrew Dunstan [EMAIL PROTECTED] wrote: Why use an absolute path? Why not just give the name of the .so and let postgres find it in $libdir (i.e. sed -e 's,/usr/local/pgsql.*/lib/,,' on your dump) ? 'cause I didn't know I could? I'll go and fix the Makefile in pg_sphere on GBORG. I might of even created this problem myself... Cheers, Rob ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] SIGSEGV taken on 8.1 during dump/reload
On Wed, 09 Nov 2005 10:42:00 -0500 Tom Lane [EMAIL PROTECTED] wrote: If pg_sphere is supplying a setup procedure that gets this wrong, yell at them. I'll just go fix it, now that I know what the right way is ;-) Thanks, Rob ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] SIGSEGV taken on 8.1 during dump/reload
When grilled further on (Tue, 08 Nov 2005 15:13:32 +0300), Teodor Sigaev [EMAIL PROTECTED] confessed: Hmm, did you recompile pg_sphere module for 8.1? Yes I did. Just did it again to make sure. Is there any way I can do a make installcheck without a reconfigure/make/install of postgresql? The db is running on port 5433, not the default of 5432. If this is a PGSphere problem, should this conversation be continued there? Thanks, Rob -- 07:01:55 up 36 days, 23:36, 7 users, load average: 3.80, 3.47, 3.17 Linux 2.6.5-02 #8 SMP Mon Jul 12 21:34:44 MDT 2004 pgp2ezjSE3mU6.pgp Description: PGP signature
Re: [HACKERS] SIGSEGV taken on 8.1 during dump/reload
When grilled further on (Tue, 08 Nov 2005 09:20:13 -0500),
Tom Lane [EMAIL PROTECTED] confessed:
Robert Creager [EMAIL PROTECTED] writes:
v-spl_right is address 0xbp - uninitialized?
The whole struct looks pretty uninitialized, which immediately makes me
wonder whether gdb has picked up a wrong value for v. Try going down
to a lower stack frame and seeing if you can access the struct from
there.
Well, it's defined the next level up on the stack, and it's still garbage. The
way I read gist.c and how it's calling gistUserPicksplit at line 1083, it's not
initialized prior that else. So, FunctionCall2 in gistutil.c is supposed to
fill it out? Presumably a function supplied by PGSphere in this case?
(gdb) up
#1 0x0807f249 in gistSplit (r=0x48df1e6c, buffer=93, itup=0x83b8e94,
len=0xbfffcea4, dist=0xbfffcea0, giststate=0xbfffd120) at gist.c:1083
(gdb) print v
$1 = {spl_left = 0x83bcd98, spl_nleft = 8, spl_ldatum = 138138032, spl_lattr =
{138089040, 1, 1075344513, 3221212168, 134843567, 0, 1076099872, 1076099872,
1076100896, 1076099944, 1076099872, 138072532, 136595410, 138072532, 127, 64,
138072596, 137900116, 138120544, 108, 8205, 1076099872, 1076097560, 1077067776,
1222874789, 2281761506, 1072462523, 8192, 1076979200, 1348122942, 3218058668,
3588489616}, spl_lattrsize = {1072628007, 1222999180, 0, -1073754968,
1222976259, -1073755008, 1079103008, 3871912, 1076979200, 8132, 32, 138120552,
58657919, 717016950, 1071875034, 1883413536, -1077677968, -817345387,
1072225709, 138043264, 138043264, 1222999180, 1222999180, -1073754936,
1222952809, 138120624, 1079103008, 138120624, 138120580, -1073754256,
-1073754256, -1073754376}, spl_lisnull = ÍD#\bàÌÿ¿\000\000\000\000(Íÿ¿0K;\b
×ÿ¿\000\000\000\000\000\000\000, spl_leftvalid = -92 '¤', spl_right = 0xdb,
spl_nright = 138138076, spl_rdatum = 11, spl_rattr = {3463919764, 0, 0, 0, 0,
1, 3221212568, 138103264, 138089640, 434176, 0, 0, 1222856988, 1222843688,
1222829704, 138103264, 3, 1075321604, 0, 1073825468, 1076097560, 3221212576,
3221212540, 1075326465, 3221212576, 909186620, 825503793, 0, 138090070,
1076097560, 136751593, 3221212860}, spl_rattrsize = {-1073754484, 1075303286,
-1073754720, 136751593, -1073754428, 138090044, 0, -1073754560, 136027536,
1079058352, 138120732, 32, 1079058312, 138090044, 138090062, 138090070, 226,
138089984, 0, 0, 0, 7904, 1024, 138120552, 138120852, 138120840, 908,
-1073754600, 13655, 138043264, 138120852, 908}, spl_risnull = \200_:[EMAIL
PROTECTED] Ñÿ¿\224\216;\b, spl_rightvalid = 108 'l', spl_idgrp = 0x83b921c,
spl_ngrp = 0x83b8e08, spl_grpflag = 0x4 Address 0x4 out of bounds}
(gdb)
--
07:38:26 up 37 days, 13 min, 6 users, load average: 3.28, 3.42, 3.43
Linux 2.6.5-02 #8 SMP Mon Jul 12 21:34:44 MDT 2004
pgpwX91hO0FtX.pgp
Description: PGP signature
Re: [Pgsphere-dev] Re: [HACKERS] SIGSEGV taken on 8.1 during
When grilled further on (Tue, 08 Nov 2005 10:06:38 -0500), Tom Lane [EMAIL PROTECTED] confessed: Does PGSphere itself have any regression tests? (Actually, running the contrib regression tests might be more relevant than the main PG tests, since several contrib modules with GIST opclasses have regression tests.) That's what I was trying to do ;-) make installcheck passes, as does make crushtest (within pg_sphere). I'll work on trying to get a small test case tonight. Otherwise, we can try SSH to my machine or a DVD. Cheers, Rob -- 08:17:03 up 37 days, 51 min, 6 users, load average: 3.70, 3.56, 3.41 Linux 2.6.5-02 #8 SMP Mon Jul 12 21:34:44 MDT 2004 pgpae0Rl7qQ8b.pgp Description: PGP signature
Re: [HACKERS] SIGSEGV taken on 8.1 during dump/reload
On Tue, 08 Nov 2005 11:12:04 -0500 Tom Lane [EMAIL PROTECTED] wrote: Teodor Sigaev [EMAIL PROTECTED] writes: Layout of GIST_SPLITVEC struct has been changed from 8.0, I'm afraid that old .so is used. spl_(right|left)valid fields was added to GIST_SPLITVEC. Does look a bit suspicious ... Robert, are you *sure* you've got the right version of pgsphere linked in? Did you compile it against the right set of Postgres header files? I copied pg_sphere into the contrib directory in 8.1.0, which is where it was built. Last night, I executed a make clean from contrib/pg_sphere, re-built make and re-installed. I checked the pg_sphere Makefile, and it references local, not absolute paths. So, I'm as sure as I can be right now. How can I check the .so files installed by the build? Do they reference an absolute path for their dependent .so files (postgres), or will they use ld.so.conf, which might then explain the problem. My ld.so.conf still points to the 8.0.2 version, as I've not switched yet to 8.1.0. In any case, why would the make installcheck work in the pg_sphere directory? That would have to use the installed libraries. I don't have the sources with me, but I'd think an index would of been created on a spoint column, but maybe not? Cheers, Rob ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Assert failure found in 8.1RC1
On Tue, 08 Nov 2005 14:09:58 -0600 Jim C. Nasby [EMAIL PROTECTED] wrote: On Fri, Nov 04, 2005 at 08:46:27PM -0400, Marc G. Fournier wrote: On Fri, 4 Nov 2005, Jim C. Nasby wrote: For all the talk about couldn't it be part of regression, I haven't seen anyone submit a patch that would test for it ... since I believe both you and Tom have both stated that for things like race conditions, I don't know that you can create reproducable cases, can you submit a patch for how you propose this should be added to the regression tests? I have an idea, but it might be better if Robert could produce a test case since it would cover both a context storm issue as well as this race condition. Actually, I have a test case. I just sent it out to Tom a couple of hours ago. The quick and dirty is that it shows the problem after running for about 20 minutes on my Xenon system with 8.1.0... I cannot get it to fail on my AMD system with a much higher load... I can send it to others who are interested. The e-mail with dump, module and script is just over 1Mb. Cheers, Rob ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Assert failure found in 8.1RC1
On Tue, 08 Nov 2005 15:36:18 -0600 Jim C. Nasby [EMAIL PROTECTED] wrote: Just to clarify, did it show the assert failure, the context switch storm, or both? I didn't try for the assert after the patch. I was developing the test when I ran across the assert problem. It should trigger the assert problem. Yes, I'd like to take a look at this if you could send it on to me. Is there any simple way to populate the database? I doubt people would be keen on having a 1MB dump in CVS... Hmmm... Should be possible to populate all the data algorithmically. For the most part, the specific data doesn't matter, just the general patterns in the data. I'll re-send the e-mail to you. Cheers, Rob ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] SIGSEGV taken on 8.1 during dump/reload
When grilled further on (Tue, 08 Nov 2005 11:12:04 -0500), Tom Lane [EMAIL PROTECTED] confessed: Teodor Sigaev [EMAIL PROTECTED] writes: Layout of GIST_SPLITVEC struct has been changed from 8.0, I'm afraid that old .so is used. spl_(right|left)valid fields was added to GIST_SPLITVEC. Does look a bit suspicious ... Robert, are you *sure* you've got the right version of pgsphere linked in? Did you compile it against the right set of Postgres header files? Strings on pg_sphere.so does contain /usr/local/pgsql810/lib. I've attached a small dump file that when I create an index on the table, it fails. It works on 225 entries, but failed on 250. Don't know if this is data dependent or size. Is that a page boundary? It seems to me that unless the right/left stuff doesn't come into play for all indexes, that stuff is built correctly. Dump command: /usr/local/pgsql810/bin/pg_dump -F c -p 5433 -d tassiv -t test_data -f index_problem.dump Created the table and index by: tassiv=# SELECT loc into test_data from catalog limit 250; tassiv=# create index test_data_index on test_data using gist( loc ); server closed the connection unexpectedly This probably means the server terminated abnormally before or while processing the request. The connection to the server was lost. Attempting reset: Failed. ! tassiv=# \d test_data Table public.test_data Column | Type | Modifiers ++--- loc| spoint | Cheers, Rob -- 19:51:58 up 37 days, 12:26, 6 users, load average: 2.15, 2.39, 2.41 Linux 2.6.5-02 #8 SMP Mon Jul 12 21:34:44 MDT 2004 index_problem.dump Description: Binary data pgp6Rs93Q3Tpv.pgp Description: PGP signature
Re: [HACKERS] SIGSEGV taken on 8.1 during dump/reload
When grilled further on (Sun, 6 Nov 2005 20:00:38 -0700), Robert Creager [EMAIL PROTECTED] confessed: Didn't set the core big enough (1Mb). It's now at 50Mb. I am using PGSphere, which should be the only gist indexes in use. gdb /usr/local/pgsql810/bin/postgres core.28053 ... warning: core file may not match specified executable file. Core was generated by `postgres: robert tassiv [local] CREATE INDEX '. Program terminated with signal 11, Segmentation fault. warning: current_sos: Can't read pathname for load map: Input/output error Cannot access memory at address 0x400d8000 #0 0x08082057 in gistUserPicksplit (r=Cannot access memory at address 0xbfffcb28 ) at gistutil.c:833 833 if (v-spl_right[v-spl_nright - 1] == InvalidOffsetNumber) (gdb) bt #0 0x08082057 in gistUserPicksplit (r=Cannot access memory at address 0xbfffcb28 ) at gistutil.c:833 Cannot access memory at address 0xbfffcb3c Unfortunately, I have to run shortly. If someone want's a 1Mb core, I have one. I'll have (presumably) more info this evening with the bigger core, Cheers, Rob -- 07:56:01 up 36 days, 30 min, 7 users, load average: 2.25, 2.31, 2.23 Linux 2.6.5-02 #8 SMP Mon Jul 12 21:34:44 MDT 2004 pgpLvPxKKjjRR.pgp Description: PGP signature
Re: [HACKERS] SIGSEGV taken on 8.1 during dump/reload
When grilled further on (Mon, 7 Nov 2005 08:07:14 -0700), Robert Creager [EMAIL PROTECTED] confessed: I'm currently attached to the dead (dying) process. spl_nright seems pretty large... (gdb) print v-spl_nright $3 = 138311580 Program received signal SIGSEGV, Segmentation fault. 0x08082057 in gistUserPicksplit (r=0x48f3f1e4, entryvec=0x83e534c, v=0xbfffcbc0, itup=0x83e3454, len=227, giststate=0xbfffd120) at gistutil.c:833 833 if (v-spl_right[v-spl_nright - 1] == InvalidOffsetNumber) (gdb) bt #0 0x08082057 in gistUserPicksplit (r=0x48f3f1e4, entryvec=0x83e534c, v=0xbfffcbc0, itup=0x83e3454, len=227, giststate=0xbfffd120) at gistutil.c:833 #1 0x0807f249 in gistSplit (r=0x48f3f1e4, buffer=8917, itup=0x83e3454, len=0xbfffcea4, dist=0xbfffcea0, giststate=0xbfffd120) at gist.c:1083 #2 0x0807c8ab in gistplacetopage (state=0xbfffcf10, giststate=0xbfffd120) at gist.c:331 #3 0x0807e2cd in gistmakedeal (state=0xbfffcf10, giststate=0xbfffd120) at gist.c:878 #4 0x0807c7e1 in gistdoinsert (r=0x48f3f1e4, itup=0x83e339c, giststate=0xbfffd120) at gist.c:299 #5 0x0807c5a6 in gistbuildCallback (index=0x48f3f1e4, htup=0x83c3de8, values=0xbfffd020, isnull=0xbfffd000 , tupleIsAlive=1 '\001', state=0xbfffd120) at gist.c:207 #6 0x080cbb14 in IndexBuildHeapScan (heapRelation=0x48f3e1cc, indexRelation=0x48f3f1e4, indexInfo=0x83c3b6c, callback=0x807c4f0 gistbuildCallback, callback_state=0xbfffd120) at index.c:1573 #7 0x0807c3b5 in gistbuild (fcinfo=0xbfffe670) at gist.c:145 #8 0x08234dfd in OidFunctionCall3 (functionId=782, arg1=1223942604, arg2=1223946724, arg3=138165100) at fmgr.c:1460 #9 0x080cb8d3 in index_build (heapRelation=0x48f3e1cc, indexRelation=0x48f3f1e4, indexInfo=0x83c3b6c) at index.c:1353 #10 0x080cacdc in index_create (heapRelationId=128249, indexRelationName=0x83a0b94 catalog_ra_decl_index, indexRelationId=128443, indexInfo=0x83c3b6c, accessMethodObjectId=783, tableSpaceId=0, classObjectId=0x83c9cfc, primary=0 '\0', isconstraint=0 '\0', allow_system_table_mods=0 '\0', skip_build=0 '\0') at index.c:757 #11 0x08110671 in DefineIndex (heapRelation=0x30f, indexRelationName=0x83a0b94 catalog_ra_decl_index, indexRelationId=0, accessMethodName=0x83a0c00 gist, tableSpaceName=0x0, attributeList=0x83a0c58, predicate=0x0, rangetable=0x0, unique=0 '\0', primary=0 '\0', isconstraint=0 '\0', is_alter_table=0 '\0', check_rights=1 '\001', skip_build=0 '\0', quiet=0 '\0') at indexcmds.c:383 #12 0x081c409b in ProcessUtility (parsetree=0x83a0c74, params=0x0, dest=0x83a0cf0, completionTag=0xbfffec00 ) at utility.c:748 #13 0x081c2b84 in PortalRunUtility (portal=0x83aad14, query=0x83a0a7c, dest=0x83a0cf0, completionTag=0xbfffec00 ) at pquery.c:987 #14 0x081c2e0b in PortalRunMulti (portal=0x83aad14, dest=0x83a0cf0, altdest=0x83a0cf0, completionTag=0xbfffec00 ) at pquery.c:1054 #15 0x081c26a6 in PortalRun (portal=0x83aad14, count=2147483647, dest=0x83a0cf0, altdest=0x83a0cf0, completionTag=0xbfffec00 ) at pquery.c:665 #16 0x081be579 in exec_simple_query (query_string=0x83a0864 CREATE INDEX catalog_ra_decl_index ON catalog USING gist (loc);) at postgres.c:1014 #17 0x081c1377 in PostgresMain (argc=4, argv=0x8345f3c, username=0x8345f14 robert) at postgres.c:3168 #18 0x08198692 in BackendRun (port=0x835ea08) at postmaster.c:2854 #19 0x081980a5 in BackendStartup (port=0x835ea08) at postmaster.c:2498 #20 0x081963fe in ServerLoop () at postmaster.c:1231 #21 0x081957aa in PostmasterMain (argc=3, argv=0x8344788) at postmaster.c:943 #22 0x08158b49 in main (argc=3, argv=0x8344788) at main.c:256 -- 22:06:46 up 36 days, 14:41, 7 users, load average: 2.22, 2.55, 3.26 Linux 2.6.5-02 #8 SMP Mon Jul 12 21:34:44 MDT 2004 pgpbpARdi4llg.pgp Description: PGP signature
Re: [HACKERS] SIGSEGV taken on 8.1 during dump/reload
When grilled further on (Mon, 7 Nov 2005 22:25:17 -0700),
Robert Creager [EMAIL PROTECTED] confessed:
Sorry, I'll just trickle out the information.
tassiv=# \d catalog_ra_decl_index
Index public.catalog_ra_decl_index
Column | Type
+---
loc| spherekey
gist, for table public.catalog
v-spl_right is address 0xbp - uninitialized?
(gdb) print *v
$2 = {spl_left = 0x83e1308, spl_nleft = 8, spl_ldatum = 138286880, spl_lattr =
{3930298096, 3929693296, 1075344513, 3928483696, 3927878896, 50331648,
1076099872, 1076099872, 1076100640, 1076099944, 1076099872, 0, 0, 0, 1,
1076099872, 46088, 24, 138269392, 108, 8205, 1076099872, 1076097560,
1077018624, 1223005861, 2281761506, 1072462523, 8192, 1076979200, 1348122942,
3218058668, 3588489616}, spl_lattrsize = {1072628007, 1223130252, 0,
-1073754968, 1223107331, -1073755008, 1196715552, 4033364, 1076979200, 8132,
32, 138269400, 58657919, 717016950, 1071875034, 1883413536, -1077677968,
-817345387, 1072225709, 138175768, 138175768, 1223130252, 1223130252,
-1073754936, 1223083881, 138269472, 1196715552, 138269472, 138269428,
-1073754256, -1073754256, -1073754376}, spl_lisnull =
ÍD#\bàÌÿ¿\000\000\000\000(Íÿ¿\2004;\b ×ÿ¿\000\000\000\000\000\000\000,
spl_leftvalid = 20 '\024', spl_right = 0xdb, spl_nright = 138286924, spl_rdatum
= 11, spl_rattr = {3463747944, 3883728496, 0, 3882518896, 3881914096, 1,
3221212568, 138097456, 138251092, 3878890096, 0, 0, 1222988060, 1222974760,
1222960776, 138097456, 3, 1075321604, 0, 1073825468, 1076097560, 3221212576,
3221212540, 1075326465, 3221212576, 909216680, 825503793, 0, 138251202,
1076097560, 136751593, 3221212860}, spl_rattrsize = {-1073754484, 1075303286,
-1073754720, 136751593, -1073754428, 138251176, 0, -1073754560, 136027536,
1196670896, 138269580, 32, 1196670856, 138251176, 138251194, 138251202, 226,
138251008, 0, 0, 0, 7904, 1024, 138269400, 138269700, 138269688, 908,
-1073754600, 13655, 138175768, 138269700, 908}, spl_risnull =
\030e\b\000¼SG\001\000\000\000XÎÿ¿¤Îÿ¿\001\000\000\000 Ñÿ¿\004Ô=\b,
spl_rightvalid = 108 'l', spl_idgrp = 0x83dd78c, spl_ngrp = 0x83dd378,
spl_grpflag = 0x4 Address 0x4 out of bounds}
When grilled further on (Mon, 7 Nov 2005 08:07:14 -0700),
Robert Creager [EMAIL PROTECTED] confessed:
I'm currently attached to the dead (dying) process. spl_nright seems pretty
large...
(gdb) print v-spl_nright
$3 = 138311580
Program received signal SIGSEGV, Segmentation fault.
0x08082057 in gistUserPicksplit (r=0x48f3f1e4, entryvec=0x83e534c,
v=0xbfffcbc0, itup=0x83e3454, len=227, giststate=0xbfffd120) at gistutil.c:833
833 if (v-spl_right[v-spl_nright - 1] == InvalidOffsetNumber)
(gdb) bt
#0 0x08082057 in gistUserPicksplit (r=0x48f3f1e4, entryvec=0x83e534c,
v=0xbfffcbc0, itup=0x83e3454, len=227, giststate=0xbfffd120) at gistutil.c:833
#1 0x0807f249 in gistSplit (r=0x48f3f1e4, buffer=8917, itup=0x83e3454,
len=0xbfffcea4, dist=0xbfffcea0, giststate=0xbfffd120) at gist.c:1083
#2 0x0807c8ab in gistplacetopage (state=0xbfffcf10, giststate=0xbfffd120) at
gist.c:331
#3 0x0807e2cd in gistmakedeal (state=0xbfffcf10, giststate=0xbfffd120) at
gist.c:878
#4 0x0807c7e1 in gistdoinsert (r=0x48f3f1e4, itup=0x83e339c,
giststate=0xbfffd120) at gist.c:299
#5 0x0807c5a6 in gistbuildCallback (index=0x48f3f1e4, htup=0x83c3de8,
values=0xbfffd020, isnull=0xbfffd000 , tupleIsAlive=1 '\001',
state=0xbfffd120)
at gist.c:207
#6 0x080cbb14 in IndexBuildHeapScan (heapRelation=0x48f3e1cc,
indexRelation=0x48f3f1e4, indexInfo=0x83c3b6c, callback=0x807c4f0
gistbuildCallback,
callback_state=0xbfffd120) at index.c:1573
#7 0x0807c3b5 in gistbuild (fcinfo=0xbfffe670) at gist.c:145
#8 0x08234dfd in OidFunctionCall3 (functionId=782, arg1=1223942604,
arg2=1223946724, arg3=138165100) at fmgr.c:1460
#9 0x080cb8d3 in index_build (heapRelation=0x48f3e1cc,
indexRelation=0x48f3f1e4, indexInfo=0x83c3b6c) at index.c:1353
#10 0x080cacdc in index_create (heapRelationId=128249,
indexRelationName=0x83a0b94 catalog_ra_decl_index, indexRelationId=128443,
indexInfo=0x83c3b6c,
accessMethodObjectId=783, tableSpaceId=0, classObjectId=0x83c9cfc,
primary=0 '\0', isconstraint=0 '\0', allow_system_table_mods=0 '\0',
skip_build=0 '\0') at index.c:757
#11 0x08110671 in DefineIndex (heapRelation=0x30f,
indexRelationName=0x83a0b94 catalog_ra_decl_index, indexRelationId=0,
accessMethodName=0x83a0c00 gist, tableSpaceName=0x0,
attributeList=0x83a0c58, predicate=0x0, rangetable=0x0, unique=0 '\0',
primary=0 '\0',
isconstraint=0 '\0', is_alter_table=0 '\0', check_rights=1 '\001',
skip_build=0 '\0', quiet=0 '\0') at indexcmds.c:383
#12 0x081c409b in ProcessUtility (parsetree=0x83a0c74, params=0x0,
dest=0x83a0cf0, completionTag=0xbfffec00 ) at utility.c:748
#13 0x081c2b84 in PortalRunUtility (portal=0x83aad14, query=0x83a0a7c,
dest=0x83a0cf0, completionTag=0xbfffec00 ) at pquery.c:987
#14 0x081c2e0b
[HACKERS] SIGSEGV taken on 8.1 during dump/reload
Hey all, I was doing a test run of a live dump from 8.0.2 to 8.1.0, and 8.1.0 took a segmentation violation 1 hour into the operation. My plan is to re-do the dump/restore, and if it fails again, to re-compile with debug and cassert, and try to get a core. The command line was (8.1.0 is on port 5433): time pg_dumpall -c -v | psql -p 5433 -d template1 template1=# select version(); version --- -- PostgreSQL 8.1.0 on i686-pc-linux-gnu, compiled by GCC gcc (GCC) 3.3.2 (Mandrake Linux 10.0 3.3.2-6mdk) (1 row) Config is: BINDIR = /usr/local/pgsql810/bin DOCDIR = /usr/local/pgsql810/doc INCLUDEDIR = /usr/local/pgsql810/include PKGINCLUDEDIR = /usr/local/pgsql810/include INCLUDEDIR-SERVER = /usr/local/pgsql810/include/server LIBDIR = /usr/local/pgsql810/lib PKGLIBDIR = /usr/local/pgsql810/lib LOCALEDIR = MANDIR = /usr/local/pgsql810/man SHAREDIR = /usr/local/pgsql810/share SYSCONFDIR = /usr/local/pgsql810/etc PGXS = /usr/local/pgsql810/lib/pgxs/src/makefiles/pgxs.mk CONFIGURE = '--enable-syslog' '--prefix=/usr/local/pgsql810' CC = gcc CPPFLAGS = -D_GNU_SOURCE CFLAGS = -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Winline -Wendif-labels -fno-strict-aliasing CFLAGS_SL = -fpic LDFLAGS = -Wl,-rpath,/usr/local/pgsql810/lib LDFLAGS_SL = LIBS = -lpgport -lz -lreadline -lncurses -lcrypt -lresolv -lnsl -ldl -lm -lbsd VERSION = PostgreSQL 8.1.0 Log snippet as follows (serverlog is empty). postgres810 is 8.1.0, postgres is 8.0.2. Nov 6 16:02:09 thunder postgres810[5238]: [1-1] LOG: autovacuum: processing database tassiv Nov 6 16:03:09 thunder postgres810[5306]: [1-1] LOG: autovacuum: processing database bacula Nov 6 16:03:12 thunder postgres[1772]: [6-1] tassiv LOG: duration: 1539387.072 ms statement: COPY public.obs_v (x, y, imag, smag, sky, chi, sharp, iter, loc, obs_id, Nov 6 16:03:12 thunder postgres[1772]: [6-2] file_id, use, solve, star_id, mag) TO stdout; Nov 6 16:04:09 thunder postgres810[5359]: [1-1] LOG: autovacuum: processing database cpan Nov 6 16:05:09 thunder postgres[1772]: [7-1] tassiv LOG: duration: 98330.722 ms statement: COPY public.tycho2 (star_id, gsc, loc, bt, e_bt, vt, e_vt, prox) TO stdout; Nov 6 16:05:09 thunder postgres810[5418]: [1-1] LOG: autovacuum: processing database dspam Nov 6 16:05:15 thunder postgres810[1773]: [20-1] tassivNOTICE: ALTER TABLE / ADD PRIMARY KEY will create implicit index catalog_pkey for table catalog Nov 6 16:05:32 thunder postgres810[1773]: [21-1] tassivNOTICE: ALTER TABLE / ADD PRIMARY KEY will create implicit index color_groups_pkey for table color_groups Nov 6 16:05:32 thunder postgres810[1773]: [22-1] tassivNOTICE: ALTER TABLE / ADD UNIQUE will create implicit index files_name_key for table files Nov 6 16:05:32 thunder postgres810[1773]: [23-1] tassivNOTICE: ALTER TABLE / ADD PRIMARY KEY will create implicit index files_pkey for table files Nov 6 16:05:32 thunder postgres810[1773]: [24-1] tassivNOTICE: ALTER TABLE / ADD PRIMARY KEY will create implicit index groups_pkey for table groups Nov 6 16:05:32 thunder postgres810[1773]: [25-1] tassivNOTICE: ALTER TABLE / ADD PRIMARY KEY will create implicit index new_reference_loc_pkey for table new_reference_loc Nov 6 16:05:32 thunder postgres810[1773]: [26-1] tassivNOTICE: ALTER TABLE / ADD UNIQUE will create implicit index nights_night_key for table nights Nov 6 16:05:32 thunder postgres810[1773]: [27-1] tassivNOTICE: ALTER TABLE / ADD PRIMARY KEY will create implicit index nights_pkey for table nights Nov 6 16:05:32 thunder postgres810[1773]: [28-1] tassivNOTICE: ALTER TABLE / ADD UNIQUE will create implicit index obs_root_obs_id_key for table obs_root Nov 6 16:05:32 thunder postgres810[1773]: [29-1] tassivNOTICE: ALTER TABLE / ADD PRIMARY KEY will create implicit index pairs_pkey for table pairs Nov 6 16:05:32 thunder postgres810[1773]: [30-1] tassivNOTICE: ALTER TABLE / ADD PRIMARY KEY will create implicit index reference_ubvri_pkey for table reference_ubvri Nov 6 16:05:34 thunder postgres810[1773]: [31-1] tassivNOTICE: ALTER TABLE / ADD PRIMARY KEY will create implicit index sites_pkey for table sites Nov 6 16:05:34 thunder postgres810[1773]: [32-1] tassivNOTICE: ALTER TABLE / ADD PRIMARY KEY will create implicit index tycho2_pkey for table tycho2 Nov 6 16:05:55 thunder postgres810[1773]: [33-1] tassivNOTICE: ALTER TABLE / ADD PRIMARY KEY will create implicit index zero_pair_pkey for table zero_pair Nov 6 16:06:10 thunder postgres810[5489]: [1-1] LOG: autovacuum: processing database template1 Nov 6 16:06:27 thunder postgres810[32258]: [1-1] LOG: server process (PID 1773) was terminated by signal 11 Nov 6 16:06:27 thunder postgres810[32258]: [2-1] LOG: terminating any other active server processes Nov 6 16:06:27 thunder postgres810[32258]: [3-1] LOG: all
Re: [HACKERS] SIGSEGV taken on 8.1 during dump/reload
When grilled further on (Sun, 06 Nov 2005 18:52:40 -0500), Andrew Dunstan [EMAIL PROTECTED] confessed: Which version is first in your path, 8.0 or 8.1? If 8.0, do you get a different result from the 8.1 binaries? 8.0 was first. I've specified the correct full path now for the executables. Also, I've actually installed the shared libraries for the types and triggers that I use on that DB. I always seem to forget that :-( But, the table/index that it dies on is not using either the trigger or non native types, unless PG isn't getting the chance to emit that it's working on the next one before it goes out to lunch? The second reload died also. If the third dies (now that the type is in place), I'll do the re-compile and core. tassiv=# \d zero_pair Table public.zero_pair Column| Type | Modifiers --+-+--- pair_id | integer | not null group_id | integer | zero_v | real| default 0 zero_v_sigma | real| default 0 zero_i | real| default 0 zero_i_sigma | real| default 0 Indexes: zero_pair_pkey PRIMARY KEY, btree (pair_id) zero_pair_group_id btree (group_id) Foreign-key constraints: zero_pair_group_id_fkey FOREIGN KEY (group_id) REFERENCES color_groups(group_id) ON DELETE CASCADE zero_pair_pair_id_fkey FOREIGN KEY (pair_id) REFERENCES pairs(pair_id) ON DELETE CASCADE tassiv=# \d zero_pair_pkey Index public.zero_pair_pkey Column | Type -+- pair_id | integer primary key, btree, for table public.zero_pair Cheers, Rob -- 19:49:33 up 35 days, 12:24, 8 users, load average: 2.93, 2.51, 2.30 Linux 2.6.5-02 #8 SMP Mon Jul 12 21:34:44 MDT 2004 ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Seeing context switch storm with 10/13 snapshot of
On Thu, 20 Oct 2005 17:35:31 -0400 Tom Lane [EMAIL PROTECTED] wrote: Robert Creager [EMAIL PROTECTED] writes: Interesting. 7.4.1 is worse for this test, as two jump up to 130k. But, my app runs fine against 7.4.1... Would it still be helpful to try and pull together a test case from my app against 8.1beta3? Yes, if you can show a case where 8.1 is much worse than 7.4 then we need to know about it yesterday. Ok. I finally have a stand alone test case that does not show that 8.1 is worse than 7.4. It shows the opposite quite nicely ;-). In tests I'm running, 7.4.1 bogs down immediately and never recovers. 8.1 behaves itself for about 20 minutes before it goes out to lunch. So, in those terms, it is worse as it looks fine at the start, but then gets progressively worse, but overall, it's much better. I have a Perl script, a Perl module and a 1Mb database (from pg_dump -F c). Are you interested at this time in receiving this? I plan on taking it home and running against my AMD system to see what it does, but that will be against 8.0 if I remember correctly, maybe 8.03. An upgrade to RC2 might occur when RC2 comes out, unless there would be great benefit on running my tests against 8.1RC1. Cheers, Rob ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[HACKERS] Assert failure found in 8.1RC1
Hey all, While trying to get a reproducible test case for my CS storm problem (see http://archives.postgresql.org/pgsql-hackers/2005-10/msg00585.php), I upgraded to 8.1RC1 and encountered the following assert: TRAP: FailedAssertion(!(shared-page_number[slotno] == pageno shared-page_status[slotno] == SLRU_PAGE_READ_IN_PROGRESS), File: slru.c, Line: 309) On the good side, I'm yet unable to get a sustained CS storm anymore with this level of code. Looks like something might changed for the better in the last 2 weeks? For the assert, I had 5 sets of my app running, each with 8 potential outstanding queries. I then threw my test at the db with 20 more queries, and took the above failure. creagrs=# select version(); version --- -- PostgreSQL 8.1RC1 on i686-pc-linux-gnu, compiled by GCC gcc (GCC) 3.3.1 (Mandrake Linux 9.2 3.3.1-2mdk) BINDIR = /usr/local/pgsql810/bin DOCDIR = /usr/local/pgsql810/doc INCLUDEDIR = /usr/local/pgsql810/include PKGINCLUDEDIR = /usr/local/pgsql810/include INCLUDEDIR-SERVER = /usr/local/pgsql810/include/server LIBDIR = /usr/local/pgsql810/lib PKGLIBDIR = /usr/local/pgsql810/lib LOCALEDIR = MANDIR = /usr/local/pgsql810/man SHAREDIR = /usr/local/pgsql810/share SYSCONFDIR = /usr/local/pgsql810/etc PGXS = /usr/local/pgsql810/lib/pgxs/src/makefiles/pgxs.mk CONFIGURE = '--enable-syslog' '--prefix=/usr/local/pgsql810' '--enable-debug' '--enable-cassert' CC = gcc CPPFLAGS = -D_GNU_SOURCE CFLAGS = -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Winline -Wendif-labels -fno-strict-aliasing -g CFLAGS_SL = -fpic LDFLAGS = -Wl,-rpath,/usr/local/pgsql810/lib LDFLAGS_SL = LIBS = -lpgport -lz -lreadline -lncurses -lcrypt -lresolv -lnsl -ldl -lm -lbsd VERSION = PostgreSQL 8.1RC1 Thanks, Rob -- Robert Creager Advisory Software Engineer Data Management Group Sun Microsystems [EMAIL PROTECTED] 303.673.2365 Office 888.912.4458 Pager ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Assert failure found in 8.1RC1
On Wed, 02 Nov 2005 15:37:05 -0500 Tom Lane [EMAIL PROTECTED] wrote: Robert Creager [EMAIL PROTECTED] writes: I can reproduce very quickly. Looks like I should try the patch in 248 first to see if it fixes 8.1RC1? Excellent. Yes, the second patch is higher priority, but please try both while you're at it. I've put in patch 2. I'm kicking the s**t out of it, with no problems so far. I'll let it run for a while longer. One note is that I did hit the CS switch problem, but with a combination of production app and my test app. But, it took much more activity, wasn't as severe (queries were typically staying 10 seconds) and the db came out of it a few minutes after my test app stopped. I'll put in the first patch and re-run the tests. Cheers, Rob ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Assert failure found in 8.1RC1
On Wed, 02 Nov 2005 15:19:44 -0500 Tom Lane [EMAIL PROTECTED] wrote: Robert Creager [EMAIL PROTECTED] writes: TRAP: FailedAssertion(!(shared-page_number[slotno] == pageno shared-page_status[slotno] == SLRU_PAGE_READ_IN_PROGRESS), File: slru.c, Line: 309) http://archives.postgresql.org/pgsql-hackers/2005-10/msg01385.php If you can reproduce the failure with any reliability, please try one or both of the proposed patches: http://archives.postgresql.org/pgsql-patches/2005-10/msg00240.php http://archives.postgresql.org/pgsql-patches/2005-10/msg00248.php Ran with both for an hour with no problem, where I could produce the ASSERT failure within minutes for the non patched version. Thanks, Rob ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Seeing context switch storm with 10/13 snapshot of
On Thu, 20 Oct 2005 21:19:18 +0100 Simon Riggs [EMAIL PROTECTED] wrote: Try this to recreate the problem: http://archives.postgresql.org/pgsql-performance/2004-04/msg00280.php Yup, that does it. Three hits the level I see with my application ~100k. Two hits about 50k, one does nothing ( 1k). Interesting. 7.4.1 is worse for this test, as two jump up to 130k. But, my app runs fine against 7.4.1... Would it still be helpful to try and pull together a test case from my app against 8.1beta3? I have not worked on it, and don't know when I'd get time to (since I have a work around). Cheers, Rob ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Seeing context switch storm with 10/13 snapshot of
On Thu, 20 Oct 2005 23:28:21 +0100 Simon Riggs [EMAIL PROTECTED] wrote: On Thu, 2005-10-20 at 14:59 -0600, Robert Creager wrote: On Thu, 20 Oct 2005 21:19:18 +0100 Simon Riggs [EMAIL PROTECTED] wrote: Try this to recreate the problem: http://archives.postgresql.org/pgsql-performance/2004-04/msg00280.php Yup, that does it. Three hits the level I see with my application ~100k. Two hits about 50k, one does nothing ( 1k). OK, good. IYKWIM Can you try a slight modification? Run 3 threads, but against 3 different otherwise identical test tables created using a name-only mod of the test script. e.g. test_data1, 2 and 3. I modified the setup to create the first table, then selected it into the second two tables, all in the same database. Created three unique indexes (when I didn't, there was no CS issue). This will hit a different pattern of lwlocks. If the CS is the same, then it will tell us that the issue is not data dependent. If the CS drops, it tells us that it is an activity performed on the precise data blocks rather than the shared data structures which is the issue. That would then account for why the effect appears to come and go in your own application, because the effect is actually dependant on the data distribution (which presumably varies in your tables). The CS is the same on both 7.4.1 and 8.1b3 (with 8.1b3 showing 100k and 7.4.1 showing 170k using three clients). I double checked the scripts to make sure... Cheers, Rob ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Seeing context switch storm with 10/13 snapshot of
On Tue, 18 Oct 2005 00:25:25 +0100 Simon Riggs [EMAIL PROTECTED] wrote: Please try this patch and see if it reduces the CS storm: http://archives.postgresql.org/pgsql-patches/2005-10/msg00091.php Yes, I will. I'd been trying to figure out what triggered it, as I was unable to reproduce it for a while, but it gets there eventually. I had just re-started with auto vacuum off, as that might be the trigger? I'll apply the patch, re-build and re-start with auto vacuum back on, they way I'm running when I know I'll see it. Do you have access to another similar machine to do comparative testing? Do you have access to another machine with different CPU arch? It would be good to firmly isolate this to a CPU architecture interaction issue. I do have access to a windows version of the DL-380 but it's only a single CPU. I've a dual AMD server at home, but I cannot run against the db there (reverse VPN?). I'd need that reproducibility Tom wanted that I have not gotten to yet. Are the Xeons particularly old models? How new is the server? It is a HP Proliant (post Compaq merger) DL-380. A couple years old. Thanks, Rob ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Seeing context switch storm with 10/13 snapshot of
On Tue, 18 Oct 2005 10:29:43 -0600 Robert Creager [EMAIL PROTECTED] wrote: On Tue, 18 Oct 2005 00:25:25 +0100 Simon Riggs [EMAIL PROTECTED] wrote: Please try this patch and see if it reduces the CS storm: Sorry, didn't work. Took about an hour, and now it's now at the CS storm (averaging 94k). I've now disabled auto vacuum, just to see if that is a trigger, and am re-running. Thanks, Rob ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Seeing context switch storm with 10/13 snapshot of
On Tue, 18 Oct 2005 12:24:03 -0600 Robert Creager [EMAIL PROTECTED] wrote: On Tue, 18 Oct 2005 10:29:43 -0600 Robert Creager [EMAIL PROTECTED] wrote: On Tue, 18 Oct 2005 00:25:25 +0100 Simon Riggs [EMAIL PROTECTED] wrote: Please try this patch and see if it reduces the CS storm: Sorry, didn't work. Took about an hour, and now it's now at the CS storm (averaging 94k). I've now disabled auto vacuum, just to see if that is a trigger, and am re-running. Vacuum (cron or auto) has no impact on the problem for 8.1beta3. Tom had mentioned running oprofile, but I'm unable to get either 0.9.1 or 0.9.0 versions of oprofile working, so looks like I'll have to get a reproducible test case... Anyone know of a script that can replay a PostgreSQL log file? Then I could log all queries, wait till the problem hits, and then replay to see if that reproduces it... Cheers, Rob ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[HACKERS] auto vacuum lock on 8.1beta1
2005): Oct 12 13:48:37 annette postgres810[20936]: [2-1] LOG: autovacuum: processing database int_test_new Oct 12 13:49:37 annette postgres810[20947]: [2-1] LOG: autovacuum: processing database creagrs Oct 12 13:50:37 annette postgres810[20957]: [2-1] LOG: autovacuum: processing database postgres Oct 12 13:51:37 annette postgres810[20967]: [2-1] LOG: autovacuum: processing database unit_test Oct 12 13:52:37 annette postgres810[20977]: [2-1] LOG: autovacuum: processing database template1 Oct 12 13:54:11 annette postgres810[21000]: [2-1] LOG: autovacuum: processing database int_test_new Oct 12 13:55:16 annette postgres810[21016]: [2-1] LOG: autovacuum: processing database creagrs Oct 12 13:56:16 annette postgres810[21033]: [2-1] LOG: autovacuum: processing database postgres Oct 12 13:57:16 annette postgres810[21043]: [2-1] LOG: autovacuum: processing database unit_test Oct 12 13:58:16 annette postgres810[21053]: [2-1] LOG: autovacuum: processing database template1 Oct 12 13:59:16 annette postgres810[21064]: [2-1] LOG: autovacuum: processing database int_test_new creagrs=# select version(); version --- PostgreSQL 8.1beta2 on i686-pc-linux-gnu, compiled by GCC gcc (GCC) 3.3.1 (Mandrake Linux 9.2 3.3.1-2mdk) -- Robert Creager Advisory Software Engineer Data Management Group Sun Microsystems [EMAIL PROTECTED] 303.673.2365 Office 888.912.4458 Pager ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] auto vacuum lock on 8.1beta1
On Thu, 13 Oct 2005 15:09:58 -0400 Tom Lane [EMAIL PROTECTED] wrote: Robert Creager [EMAIL PROTECTED] writes: Might this be the same problem as the recent thread database vacuum from cron hanging where Tom is: I'm busy volatile-izing all the code in bufmgr.c ... should be able to commit a fix soon.? Seems reasonably likely, seeing that the original report involved gcc 3.3.something IIRC, and you're using 3.3.1. Is this an SMP box? The bug could theoretically manifest on a uniprocessor but it seems more likely to happen on a multiprocessor. Yes, it's a dual Xenon box. Too bad you didn't have it built with --enable-debug; I can't think of any very easy way to verify a negative refcount for that buffer without gdb support. I just downloaded last nights snapshot. I'll build with debug and try it out. Thanks, Rob ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] auto vacuum lock on 8.1beta1
On Thu, 13 Oct 2005 14:20:46 -0500 Kevin Grittner [EMAIL PROTECTED] wrote: I can confirm that the patch was in the snapshot I picked up this morning at about 10:30 CDT. We've been using it since then and have not seen the problem in spite of attempting to provoke it with database vacuums. Thanks Kevin. I'm giving it a try now. ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[HACKERS] Seeing context switch storm with 10/13 snapshot of 8.1beta3
00 040 205 107433 45 55 0 0 7 0 1032 63832 48 160899600 056 225 113536 40 60 0 0 Help? Thanks, Rob -- Robert Creager Advisory Software Engineer Data Management Group Sun Microsystems [EMAIL PROTECTED] 303.673.2365 Office 888.912.4458 Pager ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Seeing context switch storm with 10/13 snapshot of
When grilled further on (Thu, 13 Oct 2005 22:44:54 -0400), Tom Lane [EMAIL PROTECTED] confessed: Robert Creager [EMAIL PROTECTED] writes: I've been having this problem since trying to upgrade from 7.4.1 to 8.03, and now 8.1. Can you put together a test case that other people could use to reproduce it? I can try. The data size isn't big, but the scripts that run against it are, and are dependent on our development enviornment. What I'll have to do is pull out the db portion of the app and see if I can simplify it - might work. The app is a test system that runs against our big storage libraries. Is there anything I might be able to do (without the test case) that would help figure out what's happening? Cheers, Rob -- 21:09:29 up 11 days, 12:44, 7 users, load average: 3.87, 4.27, 5.04 Linux 2.6.5-02 #8 SMP Mon Jul 12 21:34:44 MDT 2004 pgpXsXH0CCrdV.pgp Description: PGP signature
[HACKERS] date_trunc problem in HEAD
Hey All, I goofed with the patch I submitted last year for adding 'week' capability to the date_trunc function. Attached is a patch against HEAD for your review. Cheers, Rob -- 11:00:49 up 47 days, 16:17, 4 users, load average: 3.01, 2.37, 2.37 Linux 2.6.5-02 #8 SMP Mon Jul 12 21:34:44 MDT 2004 date_trunc.patch Description: Binary data pgpMzsnWN5kpL.pgp Description: PGP signature
Re: [HACKERS] date_trunc problem in HEAD
When grilled further on (Sun, 13 Mar 2005 19:40:02 +0100), Kurt Roeckx [EMAIL PROTECTED] confessed: Attached is a patch against HEAD for your review. It has this comment in it: /* the new year cannot be greater than the * original year, so we subtract one if it is Not doing to well here. When will the ISO year be greater than the current year? But, what I did is incorrect and 2006-01-01 shows the next problem date: SELECT '' AS date_trunc_week, date_trunc( 'week', timestamp '2006-01-01' ) AS week_trunc; date_trunc_week | week_trunc -+- | 2006-12-25 00:00:00 Heck, even what I submitted, test and all is wrong: SELECT '' AS date_trunc_week, date_trunc( 'week', timestamp '2005-01-01' ) AS week_trunc; date_trunc_week | week_trunc -+- | 2005-01-02 00:00:00 The date should be 2005-01-03. Sigh. Maybe I should of just submitted a bug report about it... So, unless someone else knows how to do this correctly, I'll have to actually think about it. Cheers, Rob -- 12:34:02 up 47 days, 17:50, 4 users, load average: 2.34, 2.60, 2.55 Linux 2.6.5-02 #8 SMP Mon Jul 12 21:34:44 MDT 2004 pgpsLcfsPEZ1Y.pgp Description: PGP signature
Re: [HACKERS] date_trunc problem in HEAD
OK. I believe the following function provides the correct functionality. Agree/disagree? If it's good, I'll figure out how to convert this little monster to C... CREATE OR REPLACE FUNCTION date_trunc_week(timestamp without time zone) RETURNS timestamp without time zone AS ' DECLARE reading_time ALIAS FOR $1; year timestamp; dow integer; temp interval; weeks text; adjust text; BEGIN year := date_trunc( ''year''::text, reading_time ); dow := date_part( ''dow'', year ); IF dow = 4 THEN adjust := 1 - dow || '' day''; ELSIF dow != 1 THEN adjust := dow - 6 || '' day''; ELSE adjust := ''0 day''; END IF; temp := reading_time - (year + adjust::interval); weeks := trunc(date_part( ''days'', temp ) / 7) || '' weeks''; RETURN year + adjust::interval + weeks::interval; END; ' LANGUAGE plpgsql; select date_trunc_week( '2004-01-01' ); -- 2003-12-29 00:00:00 select date_trunc_week( '2005-01-01' ); -- 2004-12-27 00:00:00 select date_trunc_week( '2005-06-01' ); -- 2005-05-30 00:00:00 select date_trunc_week( '2006-01-01' ); -- 2005-12-26 00:00:00 select date_trunc_week( '2007-01-01' ); -- 2007-01-01 00:00:00 Thanks for your input on this Kurt. Cheers, Rob -- 21:48:49 up 48 days, 3:05, 4 users, load average: 3.80, 3.13, 2.82 Linux 2.6.5-02 #8 SMP Mon Jul 12 21:34:44 MDT 2004 pgp7qKDfwTHuS.pgp Description: PGP signature
Re: [HACKERS] Comments on patch for date_trunc( 'week', ... );
When grilled further on (Wed, 3 Mar 2004 22:40:50 -0500 (EST)), Bruce Momjian [EMAIL PROTECTED] confessed: Well, it must have hit the lists if I have put it in the patch queue, no? --- Hey Bruce, I never saw the patch hit the hackers list. Did any of you smart folks take a look at it? More emphasis on the latter, less on the former. That was the gist of the e-mail, to make sure someone else actually looked at it ;-) Later, Rob -- 20:44:41 up 18 days, 4:22, 3 users, load average: 1.04, 1.12, 1.15 Linux 2.4.21-0.13_test #60 SMP Sun Dec 7 17:00:02 MST 2003 pgpYmHt2hlUj8.pgp Description: PGP signature
Re: [HACKERS] pgAdmin
When grilled further on (29 Feb 2004 08:46:36 -0800), [EMAIL PROTECTED] (Hammer) confessed: Quick one: Anyone know how to use Putty to open a connection up under SSH which will allow pgAdmin III to connect to a postgresql database ie. Only access to server postgresql is on is via ssh. Trivial. In the connection configuration within PuTTY, Connection/SSH/Tunnels, fill in source port ( for instance), destination (machine:5432), select 'Local' radio and click Add. Save the connection, then open it. In this instance, from pgAdmin (I'm using pgAdmin II V1.6), host is 'localhost', port ''. Cheers, Rob -- 17:03:13 up 15 days, 42 min, 4 users, load average: 2.08, 2.19, 2.27 Linux 2.4.21-0.13_test #60 SMP Sun Dec 7 17:00:02 MST 2003 pgpCYUfzMxhcO.pgp Description: PGP signature
[HACKERS] Comments on patch for date_trunc( 'week', ... );
Per a brief conversation with Tom, I've created a patch for adding support for 'week' within the date_trunc function. Within the patch I added a couple of test cases and associated target output, and changed the documentation to add 'week' appropriately. Comments? Should I of bypassed this list and subscribed/posted to the patch list? Cheers, Rob -- 17:07:39 up 15 days, 46 min, 4 users, load average: 2.18, 2.23, 2.27 Linux 2.4.21-0.13_test #60 SMP Sun Dec 7 17:00:02 MST 2003 date_trunc.patch Description: Binary data pgpUKUkBmR9YU.pgp Description: PGP signature
Re: [HACKERS] Comments on patch for date_trunc( 'week', ... );
Hey Bruce, I never saw the patch hit the hackers list. Did any of you smart folks take a look at it? Cheers, Rob When grilled further on (Wed, 3 Mar 2004 13:58:02 -0500 (EST)), Bruce Momjian [EMAIL PROTECTED] confessed: Your patch has been added to the PostgreSQL unapplied patches list at: http://momjian.postgresql.org/cgi-bin/pgpatches I will try to apply it within the next 48 hours. --- Robert Creager wrote: -- Start of PGP signed section. Per a brief conversation with Tom, I've created a patch for adding support for'week' within the date_trunc function. Within the patch I added a couple of test cases and associated target output, and changed the documentation to add 'week' appropriately. Comments? Should I of bypassed this list and subscribed/posted to the patch list? Cheers, Rob -- 17:07:39 up 15 days, 46 min, 4 users, load average: 2.18, 2.23, 2.27 Linux 2.4.21-0.13_test #60 SMP Sun Dec 7 17:00:02 MST 2003 [ Attachment, skipping... ] -- End of PGP section, PGP failed! -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 -- 20:21:06 up 18 days, 3:59, 2 users, load average: 1.52, 1.31, 1.25 Linux 2.4.21-0.13_test #60 SMP Sun Dec 7 17:00:02 MST 2003 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] pgAdmin
When grilled further on (29 Feb 2004 08:46:36 -0800), [EMAIL PROTECTED] (Hammer) confessed: Quick one: Anyone know how to use Putty to open a connection up under SSH which will allow pgAdmin III to connect to a postgresql database ie. Only access to server postgresql is on is via ssh. Trivial. In the connection configuration within PuTTY, Connection/SSH/Tunnels, fill in source port ( for instance), destination (machine:5432), select 'Local' radio and click Add. Save the connection, then open it. In this instance, from pgAdmin (I'm using pgAdmin II V1.6), host is 'localhost', port ''. Cheers, Rob -- 17:03:13 up 15 days, 42 min, 4 users, load average: 2.08, 2.19, 2.27 Linux 2.4.21-0.13_test #60 SMP Sun Dec 7 17:00:02 MST 2003 pgp0.pgp Description: PGP signature
Re: [HACKERS] pg_dump bug in 7.4
When grilled further on (Sat, 4 Oct 2003 12:50:27 -0500), Bruno Wolff III [EMAIL PROTECTED] confessed: The following is still a problem in current cvs (as of 2 hours ago). Normally I wouldn't bug people about this again this soon, but with talk of a release candidate next week I wanted to make sure that it wasn't forgotten. I just hit the same problem (with 7.4b4). CREATE TABLE processing ( index integer NOT NULL, time timestamp with time zone DEFAULT now() NOT NULL, archname_index integer, CONSTRAINT archname_index CHECK NULL::boolean ); Cheers, Rob -- 11:49:30 up 64 days, 4:19, 4 users, load average: 4.37, 3.83, 3.53 pgp0.pgp Description: PGP signature
Re: [HACKERS] Header files installed for contrib modules?
On Sat, 23 Aug 2003 21:16:38 +0200 (CEST) Peter Eisentraut [EMAIL PROTECTED] said something like: Robert Creager writes: Just wondering if there is currently any mechanism in the contrib makefile hierarchy for installing header files into an appropriate directory. There isn't, because until now there was no need for it. But there is no reason that it couldn't be added. So would one of you fine hackers be willing to add this feature? If not, I'll have a go of it. Would this be best accomplished using a sub-directory which contains the header files to install, or a make variable containing the headers? Cheers, Rob -- 17:11:53 up 22 days, 9:53, 4 users, load average: 2.34, 2.18, 2.05 pgp0.pgp Description: PGP signature
[HACKERS] Header files installed for contrib modules?
Hey, Just wondering if there is currently any mechanism in the contrib makefile hierarchy for installing header files into an appropriate directory. I didn't find anything. I'm using PGSphere (spherical types/operators), and trying to help them out a little here and there. When I converted my application over to use their type/operators, I found that although the shared library is installed fine, there appears to be no method for installing the header files into the production directory scheme. Since the library is installed into the pgsql/lib directory, shouldn't the header files required by server side development be installed into pgsql/include? Maybe not by default, but with a 'install-all-headers' like option? Thanks, Rob -- 22:05:34 up 21 days, 14:47, 4 users, load average: 2.01, 2.03, 2.00 pgp0.pgp Description: PGP signature
[HACKERS] 7.4 Beta1: variable not found in subplan target lists
Hey again,
Received this error:
Aug 6 16:24:55 thunder postgres[7835]: [11-1] ERROR: variable not
found in subplan target lists
during this query:
$dbh-do( qq/
DELETE FROM temp_obs_v
WHERE file_id IN
(SELECT file_id
FROM temp_obs_v NATURAL JOIN files
WHERE group_id = $group_id
AND pair_id = $pair_id) /);
on the 15th iteration (the previous 14 worked fine).
It is repeatable. Something stupid again (other than the duplicate
indexes)?
tassiv=# explain DELETE FROM temp_obs_i
tassiv-# WHERE file_id IN
tassiv-#(SELECT file_id
tassiv(# FROM temp_obs_i NATURAL JOIN files
tassiv(# WHERE group_id = 3
tassiv(#AND pair_id = 25)
tassiv-# ;
ERROR: variable not found in subplan target lists
tassiv=# \d temp_obs_i
Table public.temp_obs_i
Column | Type | Modifiers
-+-+
x | real| not null
y | real| not null
imag| real| not null
smag| real| not null
loc | spoint | not null
obs_id | integer | not null default nextval('obs_id_seq'::text)
file_id | integer | not null
use | boolean | default false
solve | boolean | default false
star_id | integer |
mag | real|
Indexes:
temp_obs_i_file_id_index btree (file_id)
temp_obs_i_index gist (loc)
temp_obs_i_loc_index gist (loc)
temp_obs_i_obs_id_index btree (obs_id)
Foreign-key constraints:
temp_obs_i_files_constraint FOREIGN KEY (file_id) REFERENCES
files(file_id) ON DELETE CASCADE Inherits: obs_root
tassiv=# \d files
Table public.files
Column | Type | Modifiers
--+--+-
-- file_id | integer | not null
default nextval('files_file_id_seq'::text) group_id | integer
| pair_id | integer |
date | timestamp with time zone | not null
name | character varying| not null
ra_min | real | default 0
ra_max | real | default 0
dec_min | real | default 0
dec_max | real | default 0
Indexes:
files_pkey primary key, btree (file_id)
files_name_key unique, btree (name)
files_id_index btree (file_id, group_id, pair_id)
files_range_index btree (ra_min, ra_max, dec_min, dec_max)
Foreign-key constraints:
$1 FOREIGN KEY (group_id) REFERENCES groups(group_id) ON DELETE
CASCADE$2 FOREIGN KEY (pair_id) REFERENCES pairs(pair_id) ON
DELETE CASCADE
--
19:43:52 up 5 days, 12:30, 3 users, load average: 2.11, 2.07, 2.01
pgp0.pgp
Description: PGP signature
[HACKERS] 7.4Beta1 hang?
I appear to have a hang on my system (40 minutes so far, it's now
17:40). The code is from CVS updated 8/6 if I remember correctly.
The machine is idle, with a vacuum waiting and an INSERT doing nothing.
The vacuum is being generated via pg_autovacuum.
The output from the perl script leading up to the hang is:
2755/kir_27551925.fits.apm... 1775 stars imported 3421 per second
2755/kvr_27551925.fits.apm... 1219 stars imported 4639 per second
.Kept 925 (75.9%) pairs of stars at 249.9 per second ( 3.7)
2755/kir_27551989.fits.apm... 1727 stars imported 3564 per second
2755/kvr_27551989.fits.apm... 918 stars imported 3518 per second
.Kept 694 (75.6%) pairs of stars at 635.3 per second ( 1.1)
2755/kir_27552015.fits.apm... 1817 stars imported 4549 per second
2755/kvr_27552015.fits.apm... 958 stars imported 4197 per second
As you this shows, the insert that is hung is part of a series of
operaqtions which usually completes in under 4 seconds.
The insert is:
INSERT INTO obs_i
SELECT *
FROM temp_obs_i
WHERE obs_id IN (SELECT i_obs_id FROM obs_keep)
The PostgreSQL processes:
postgres 32242 1 0 Aug07 ?00:00:01
/usr/local/pgsql/bin/postmaster -D /var/lib/pgsql/data postgres 32246
32242 0 Aug07 ?00:02:38 postgres: stats buffer process
postgres 32247 32246 0 Aug07 ?00:02:30
postgres: stats collector process
postgres 6426 32242 32 16:36 ?00:09:21
postgres: robert tassiv 192.168.0.250 INSERT
postgres 6427 32242 1 16:36 ?00:00:21
postgres: robert tassiv 192.168.0.250 idle
postgres 6615 32242 3 16:48 ?00:00:34
postgres: robert tassiv localhost VACUUM waiting
postgres 6824 32242 0 17:01 ?00:00:00
postgres: checkpoint subprocess
Anything to look at before I kick it? It's not built with debug, but I
can still get a backtrace.
Tables:
obs_keep is a temp table generated via perl script
SELECT i.obs_id AS i_obs_id,
v.obs_id AS v_obs_id
INTO TEMP obs_keep
FROM
(SELECT obs_id, file_id, loc
FROM temp_obs_v NATURAL JOIN files
WHERE group_id = $group_id
AND pair_id = $pair_id) AS v,
(SELECT obs_id, file_id, loc
FROM temp_obs_i NATURAL JOIN files
WHERE group_id = $group_id
AND pair_id = $pair_id) AS i
WHERE i.loc @ scircle( v.loc, $MATCH_RADIUS )
tassiv=# \d temp_obs_i
Table public.temp_obs_i
Column | Type | Modifiers
-+-+
x | real| not null
y | real| not null
imag| real| not null
smag| real| not null
loc | spoint | not null
obs_id | integer | not null default nextval('obs_id_seq'::text)
file_id | integer | not null
use | boolean | default false
solve | boolean | default false
star_id | integer |
mag | real|
Indexes:
temp_obs_i_file_id_index btree (file_id)
temp_obs_i_index gist (loc)
temp_obs_i_loc_index gist (loc)
temp_obs_i_obs_id_index btree (obs_id)
Foreign-key constraints:
temp_obs_i_files_constraint FOREIGN KEY (file_id) REFERENCES
files(file_id) ON DELETE CASCADE Inherits: obs_root
tassiv=# \d obs_i
Table public.obs_i
Column | Type | Modifiers
-+-+
x | real| not null
y | real| not null
imag| real| not null
smag| real| not null
loc | spoint | not null
obs_id | integer | not null default nextval('obs_id_seq'::text)
file_id | integer | not null
use | boolean | default false
solve | boolean | default false
star_id | integer |
mag | real|
Indexes:
obs_i_file_id_index btree (file_id)
obs_i_loc_index gist (loc)
obs_i_obs_id_index btree (obs_id)
obs_i_star_id_index btree (star_id)
obs_i_use_index btree (use)
Foreign-key constraints:
obs_i_files_constraint FOREIGN KEY (file_id) REFERENCES
files(file_id) ON DELETE CASCADEobs_i_star_id_constraint FOREIGN
KEY (star_id) REFERENCES catalog(star_id) ON DELETE SET NULL Triggers:
obs_i_trig BEFORE INSERT OR DELETE OR UPDATE ON obs_i FOR EACH ROW
EXECUTE PROCEDURE observations_trigger()
Inherits: obs_root
--
17:05:52 up 8 days, 9:51, 4 users, load average: 0.03, 0.51, 0.92
pgp0.pgp
Description: PGP signature
Re: [HACKERS] 7.4Beta1 hang?
On Sat, 09 Aug 2003 21:17:05 -0400 Tom Lane [EMAIL PROTECTED] said something like: Robert Creager [EMAIL PROTECTED] writes: [much data] Could you supply the relation names corresponding to the relation OIDs appearing in pg_locks, so we can be sure who's processing what? Well, there appears to be a mail problem. Not sure if it's on my end, or somewhere else. I dug around a little and I might have what you asked for. The relname looks correct for what's currently being processed, but I don't know why some of the relation wouldn't have a name. Of course, I made this up, so it may be vey wrong... tassiv=# select relation, mode, relname from pg_locks left join pg_class on ( pg_locks.relation = pg_class.relfilenode ); relation | mode | relname --+--+--- 1259 | AccessShareLock | pg_class 16759 | AccessShareLock | pg_locks 17835 | AccessShareLock | groups 17835 | RowShareLock | groups 17844 | AccessShareLock | pairs_pair_id_seq 17846 | AccessShareLock | pairs 17846 | RowShareLock | pairs 17846 | RowExclusiveLock | pairs 17855 | AccessShareLock | files_file_id_seq 17857 | AccessShareLock | files 17857 | RowShareLock | files 17857 | RowExclusiveLock | files 17879 | AccessShareLock | fits 17879 | RowExclusiveLock | fits 17912 | AccessShareLock | obs_id_seq 17971 | AccessShareLock | obs_v 17971 | RowExclusiveLock | obs_v 17984 | AccessShareLock | temp_obs_v 17984 | RowExclusiveLock | temp_obs_v 17984 | ShareLock| temp_obs_v 17984 | AccessExclusiveLock | temp_obs_v 18015 | ShareUpdateExclusiveLock | obs_i 18015 | AccessShareLock | obs_i 18015 | RowExclusiveLock | obs_i 18015 | ShareUpdateExclusiveLock | obs_i 18028 | AccessShareLock | temp_obs_i 18028 | RowExclusiveLock | temp_obs_i 18028 | ShareLock| temp_obs_i 18028 | AccessExclusiveLock | temp_obs_i 18045 | AccessShareLock | imported 18045 | RowExclusiveLock | imported 18096 | AccessExclusiveLock | obs_i_loc_index 18096 | AccessExclusiveLock | obs_i_loc_index 18099 | ShareLock| 18099 | AccessExclusiveLock | 18101 | ShareLock| 18101 | AccessExclusiveLock | 34526324 | AccessShareLock | 34526324 | ShareLock| 34526324 | AccessExclusiveLock | 34527019 | ShareLock| 34527019 | AccessExclusiveLock | 34527020 | ShareLock| 34527020 | AccessExclusiveLock | | ExclusiveLock| | ExclusiveLock| | ExclusiveLock| -- 09:02:24 up 9 days, 1:47, 4 users, load average: 2.01, 2.03, 2.00 pgp0.pgp Description: PGP signature
Re: [HACKERS] 7.4Beta1 hang?
On Sat, 09 Aug 2003 20:12:36 -0400 Tom Lane [EMAIL PROTECTED] said something like: Robert Creager [EMAIL PROTECTED] writes: Anything to look at before I kick it? pg_locks and pg_stat_activity, if you can select from them in a non-stuck backend. tassiv=# select * from pg_locks; relation | database | transaction | pid | mode | granted --+--+-+--+--+- 17846 |17140 | | 6426 | AccessShareLock | t 17846 |17140 | | 6426 | RowShareLock | t 17846 |17140 | | 6426 | RowExclusiveLock | t 17835 |17140 | | 6426 | AccessShareLock | t 17835 |17140 | | 6426 | RowShareLock | t 18096 |17140 | | 6426 | AccessExclusiveLock | t 18045 |17140 | | 6426 | AccessShareLock | t 18045 |17140 | | 6426 | RowExclusiveLock | t 34527020 |17140 | | 6426 | ShareLock| t 34527020 |17140 | | 6426 | AccessExclusiveLock | t 18015 |17140 | | 6615 | ShareUpdateExclusiveLock | t 17971 |17140 | | 6426 | AccessShareLock | t 17971 |17140 | | 6426 | RowExclusiveLock | t 16759 |17140 | | 8069 | AccessShareLock | t 34526324 |17140 | | 6426 | AccessShareLock | t 34526324 |17140 | | 6426 | ShareLock| t 34526324 |17140 | | 6426 | AccessExclusiveLock | t 18101 |17140 | | 6426 | ShareLock| t 18101 |17140 | | 6426 | AccessExclusiveLock | t 18096 |17140 | | 6615 | AccessExclusiveLock | f 18028 |17140 | | 6426 | AccessShareLock | t 18028 |17140 | | 6426 | RowExclusiveLock | t 18028 |17140 | | 6426 | ShareLock| t 18028 |17140 | | 6426 | AccessExclusiveLock | t 17879 |17140 | | 6426 | AccessShareLock | t 17879 |17140 | | 6426 | RowExclusiveLock | t | | 79764 | 8069 | ExclusiveLock| t 18015 |17140 | | 6426 | AccessShareLock | t 18015 |17140 | | 6426 | RowExclusiveLock | t | | 79690 | 6615 | ExclusiveLock| t 17855 |17140 | | 6426 | AccessShareLock | t 17857 |17140 | | 6426 | AccessShareLock | t 17857 |17140 | | 6426 | RowShareLock | t 17857 |17140 | | 6426 | RowExclusiveLock | t 18099 |17140 | | 6426 | ShareLock| t 18099 |17140 | | 6426 | AccessExclusiveLock | t 17912 |17140 | | 6426 | AccessShareLock | t | | 79712 | 6426 | ExclusiveLock| t 17984 |17140 | | 6426 | AccessShareLock | t 17984 |17140 | | 6426 | RowExclusiveLock | t 17984 |17140 | | 6426 | ShareLock| t 17984 |17140 | | 6426 | AccessExclusiveLock | t 17844 |17140 | | 6426 | AccessShareLock | t 34527019 |17140 | | 6426 | ShareLock| t 34527019 |17140 | | 6426 | AccessExclusiveLock | t 18015 |17140 | | 6615 | ShareUpdateExclusiveLock | t tassiv=# select * from pg_stat_activity; datid | datname | procpid | usesysid | usename | current_query | query_start ---+-+-+--+-+---+- 17140 | tassiv |8069 | 100 | robert | | 17140 | tassiv |6426 | 100 | robert | | 17140 | tassiv |6427 | 100 | robert | | 17140 | tassiv |6615 | 100 | robert | | It's not built with debug, but I can still get a backtrace. Might be useful. regards, tom lane 00:00:01 /usr/local/pgsql/bin/postmaster -D /var/lib/pgsql/data #0 0x4031fec2 in select () from /lib/i686/libc.so.6 #1 0xb368 in ?? () #2 0x081340bd in PostmasterMain () #3 0x08109edc in main () #4 0x4025e7f7 in __libc_start_main () from /lib/i686/libc.so.6 postgres: robert tassiv 192.168.0.250 INSERT (gdb) backtrace #0 0x403279d7 in semop () from /lib/i686/libc.so.6 #1 0x08133151 in PGSemaphoreLock () #2 0x081517cc in LWLockAcquire () #3 0x081482fd in LockBuffer () #4 0x0808439f in _bt_getbuf () #5 0x080827e4 in _bt_split () #6 0x08082202 in _bt_insertonpg () #7
Re: [HACKERS] 7.4 Beta1 elog problem
On Wed, 06 Aug 2003 15:41:47 -0700 Joe Conway [EMAIL PROTECTED] said something like: Robert Creager wrote: psql:dbTriggers.sql:30: ERROR: could not load library /usr/local/pgsql/triggers/tassiv_triggers.so: /usr/local/pgsql/triggers/tassiv_triggers.so: undefined symbol: elog Am I missing something? I was previously running 7.3.3... elog is defined now as a macro (in utils/elog.h). Did you recompile your trigger function after installing 7.4? Joe Sigh... I did, multiple times, but I didn't pay enough attention. The .o was not rebuilding. The .so was. Thanks for the tip. Cheers, Rob -- 19:38:57 up 5 days, 12:25, 3 users, load average: 2.08, 2.06, 2.01 pgp0.pgp Description: PGP signature
[HACKERS] 7.4 Beta1 elog problem
I grabbed REL7_4_BETA1 from cvs this morning, and am having a problem. A trigger I wrote uses 'elog', which is apparently not defined any more in my build. The documentation doesn't build (my problem), but doc/src/sgml/spi.sgml indicates that elog should be valid. The error I receive when installing the trigger is: psql:dbTriggers.sql:30: ERROR: could not load library /usr/local/pgsql/triggers/tassiv_triggers.so: /usr/local/pgsql/triggers/tassiv_triggers.so: undefined symbol: elog Am I missing something? I was previously running 7.3.3... Thanks, Rob -- 10:22:20 up 5 days, 3:08, 3 users, load average: 2.09, 2.10, 2.04 pgp0.pgp Description: PGP signature
Re: [HACKERS] 7.4Beta1 hang?
On Sat, 09 Aug 2003 21:17:05 -0400 Tom Lane [EMAIL PROTECTED] said something like: Could you supply the relation names corresponding to the relation OIDs appearing in pg_locks, so we can be sure who's processing what? Sure, if you tell me how ;-) I looked at the view definition and that didn't help me much... -- 19:32:24 up 8 days, 12:18, 4 users, load average: 2.07, 2.05, 2.00 pgp0.pgp Description: PGP signature
[HACKERS] FAQ programming entry?
Hey Guys, I'm working on translating my system to use pg_sphere. The question I have, which I think would make a good FAQ entry (or section is usage example?), is that I have a C language trigger function. How do I use spoint (and other types) internal to that set of functions? Note that I am being deliberately lazy here, as I'm sure I could figure it out looking at the source code, but I don't find anything in the document which would help me. Additionally, I don't see any header files installed in the pgsql directory tree related to pg_sphere... Do you want me to try and write this? Cheers, Rob -- 14:29:11 up 9 days, 18:29, 2 users, load average: 2.01, 2.02, 2.00 pgp0.pgp Description: PGP signature
Re: [HACKERS] FAQ programming entry?
Sorry, wrong list... On Sun, 27 Jul 2003 14:37:59 -0600 Robert Creager [EMAIL PROTECTED] said something like: Hey Guys, I'm working on translating my system to use pg_sphere. The question I have, which I think would make a good FAQ entry (or section is usage example?), is that I have a C language trigger function. How do I use spoint (and other types) internal to that set of functions? Note that I am being deliberately lazy here, as I'm sure I could figure it out looking at the source code, but I don't find anything in the document which would help me. Additionally, I don't see any header files installed in the pgsql directory tree related to pg_sphere... Do you want me to try and write this? Cheers, Rob -- 14:29:11 up 9 days, 18:29, 2 users, load average: 2.01, 2.02, 2.00 -- 15:30:40 up 9 days, 19:31, 2 users, load average: 2.00, 2.00, 2.00 pgp0.pgp Description: PGP signature
Re: [HACKERS] parallel regression test failure
On Sat, 26 Jul 2003 01:00:46 -0400 Tom Lane [EMAIL PROTECTED] said something like: Bruce Momjian [EMAIL PROTECTED] writes: I run it every night and it fails 25% of the time. When did you start seeing the problem? I just wasted an hour running eighty-some iterations of make check on two different machines/OSes/architectures. Zero failures. I also eyeballed recent changes in the relcache/catcache area, which seems to be what's unhappy, without finding anything. I think it's up to yunz as are seeing misbehavior to roll up your sleeves and debug the problem. There's nothing more I can do. Any suggestions for those of us who are not pg developers how I might help figure out what's up? 1 of25 - failed 0 (0%) 2 of25 - failed 0 (0%) 3 of25 - failed 0 (0%) 4 of25 - failed 0 (0%) 5 of25 - failed 0 (0%) 6 of25 - failed 0 (0%) 7 of25 - failed 0 (0%) 8 of25 - failed 0 (0%) 9 of25 - failed 0 (0%) 10 of25 - failed 0 (0%) 11 of25 - failed 1 (9%) 12 of25 - failed 2 (17%) 13 of25 - failed 2 (15%) 14 of25 - failed 2 (14% 15 of25 - failed 3 (20%) 16 of25 - failed 3 (19%) 17 of25 - failed 3 (18%) 18 of25 - failed 4 (22%) 19 of25 - failed 4 (21%) 20 of25 - failed 4 (20%) 21 of25 - failed 5 (24%) 22 of25 - failed 6 (27%) 23 of25 - failed 6 (26%) 24 of25 - failed 7 (29%) 25 of25 - failed 8 (32%) constraints failed 1 times cluster failed 1 times foreign_key failed 1 times misc failed 6 times sanity_check failed 3 times inherit failed 2 times triggers failed 4 times -- 08:21:18 up 8 days, 12:22, 2 users, load average: 0.08, 0.65, 1.58 pgp0.pgp Description: PGP signature
Re: [HACKERS] parallel regression test failure
On Sat, 26 Jul 2003 10:47:12 -0400 (EDT) Bruce Momjian [EMAIL PROTECTED] said something like: If you would like to do the cvs -d testing yourself instead of me, let me know. It will take me a few hours to get to it anyway. I will start doing pulling down old versions (once I figure out the -d syntax). Do you recall how long you may of been seeing this? Thanks, Rob -- 08:54:59 up 8 days, 12:55, 2 users, load average: 2.38, 1.12, 1.14 pgp0.pgp Description: PGP signature
Re: [HACKERS] parallel regression test failure
On Sat, 26 Jul 2003 10:47:12 -0400 (EDT) Bruce Momjian [EMAIL PROTECTED] said something like: If you would like to do the cvs -d testing yourself instead of me, let me know. It will take me a few hours to get to it anyway. Just to make sure I've got this right: cvs update -D -mm-dd make maintainer-clean ./configure make test -- 09:05:56 up 8 days, 13:06, 2 users, load average: 2.59, 2.90, 2.14 pgp0.pgp Description: PGP signature
Re: [HACKERS] parallel regression test failure
./configure --with-pgport=5433 --prefix=/usr/local/pgsql_cvs The failure moves around (out of 25 tests): constraints failed 1 times cluster failed 1 times foreign_key failed 1 times misc failed 6 times sanity_check failed 3 times inherit failed 2 times triggers failed 4 times Have not tried install check yet. On Sat, 26 Jul 2003 11:06:21 -0400 Tom Lane [EMAIL PROTECTED] said something like: - what configure options are you using? - can you reproduce the problem with serial tests (make installcheck)?- exactly how repeatable is it --- when it fails, is it always at the same places, or do the failures move around? -- 09:22:25 up 8 days, 13:23, 2 users, load average: 1.36, 1.26, 1.70 pgp0.pgp Description: PGP signature
Re: [HACKERS] parallel regression test failure
On Sat, 26 Jul 2003 11:22:21 -0400 Tom Lane [EMAIL PROTECTED] said something like: Robert Creager [EMAIL PROTECTED] writes: Just to make sure I've got this right: cvs update -D -mm-dd make maintainer-clean ./configure make test I'd do the make maintainer-clean before cvs update'ing, but otherwise probably right. Watch the output the first couple times and make sure cvs is actually willing to replace files in both the forward and backward directions. Yeah, and yeah, it just removed src/tools/pgtest when I went back to April... -- 09:36:18 up 8 days, 13:37, 2 users, load average: 0.08, 0.86, 1.54 pgp0.pgp Description: PGP signature
Re: [HACKERS] parallel regression test failure
On Sat, 26 Jul 2003 16:40:27 -0400 (EDT) Bruce Momjian [EMAIL PROTECTED] said something like: That is a very good guess. All the errors seem related to the parser. Everyone gets lucky now and then ;-) I'm now using bison 1.5 2003-01-22 did not fail in 50 tests. 2003-01-26 has not failed yet in 33 of 50 tests. 2003-01-28 and 2003-02-15 are compiled and waiting... 2003-02-01 fails, but only 2 time in 50 tests: *** ./expected/domain.out Sat Jul 26 12:24:18 2003 --- ./results/domain.outSat Jul 26 12:56:01 2003 *** *** 263,269 insert into domcontest values (5); alter domain con drop constraint t; insert into domcontest values (-5); --fails ! ERROR: ExecEvalConstraintTest: Domain con constraint $1 failed insert into domcontest values (42); -- cleanup drop domain ddef1 restrict; --- 263,269 insert into domcontest values (5); alter domain con drop constraint t; insert into domcontest values (-5); --fails ! ERROR: ExecEvalConstraintTest: Domain con constraint failed insert into domcontest values (42); -- cleanup drop domain ddef1 restrict; == -- 14:52:02 up 8 days, 18:52, 2 users, load average: 3.69, 3.40, 2.57 pgp0.pgp Description: PGP signature
Re: [HACKERS] I might be getting closer?
On Sat, 26 Jul 2003 16:49:27 -0400 (EDT) Bruce Momjian [EMAIL PROTECTED] said something like: [ cc to hackers] It certainly looks closer, particularly because the failure is s simple domain constraint failure and not a more internal error. Have you tried moving ahead a few days to see if the bug was fixed in CVS? No. I'll run 2003-02-15 next. I just got the domain failure on 2003-01-26 after 42 passes. -- 15:03:30 up 8 days, 19:04, 2 users, load average: 2.40, 2.15, 2.31 pgp0.pgp Description: PGP signature
[HACKERS] Regression test failure date.
I found it (I think)... Looks like something was done after the 15'th... 2003-02-15 passes 50/50 and 33/33 on second pass (so far) 2003-02-16 fails 6/50 vacuum failed 1 times misc failed 3 times sanity_check failed 3 times inherit failed 1 times triggers failed 4 times 2003-02-18 fails 11/50 constraints failed 5 times sanity_check failed 3 times misc failed 8 times inherit failed 2 times rules failed 1 times triggers failed 5 times Cheers, Rob -- 17:42:41 up 8 days, 21:43, 2 users, load average: 3.62, 2.69, 2.35 pgp0.pgp Description: PGP signature
Re: [HACKERS] Regression test failure date.
On Sat, 26 Jul 2003 20:24:56 -0400 Tom Lane [EMAIL PROTECTED] said something like: What time of day did your successive pulls correspond to, anyway? (I believe my cvs2cl printout above is showing me EST.) regards, tom lane I'm MST, and I did not specify a timezone on the cvs updates. just cvs update -D 2003-02-16 I can re-do with a specific time/date if you tell me what you want. Or give me a range. I take a few minutes to do a complete cvs download. Later, Rob -- 19:10:13 up 8 days, 23:10, 2 users, load average: 0.00, 0.00, 0.00 pgp0.pgp Description: PGP signature
Re: [HACKERS] Regression test failure date.
On Sat, 26 Jul 2003 21:08:46 -0400 (EDT)
Bruce Momjian [EMAIL PROTECTED] said something like:
I am seeing repeatable success from a CVS of 2003-05-01, and
repeatable failure from current CVS.
I have only been running nightly paralell regression runs since June
27, so it is possible that the paralell regression was broken in
February, fixed in May, then broken some time after that.
I will test June 1 now.
I don't know about that Bruce. When I grabbed 2003-05-01, I have 2
failures in 15 runs so far. One item I did have to change was to move
from bison 1.5 to bison 1.875.
I've attached included the first failure one.
*** ./expected/triggers.out Sat Nov 23 11:13:22 2002
--- ./results/triggers.out Sat Jul 26 20:10:18 2003
***
*** 87,92
--- 87,93
NOTICE: check_pkeys_fkey_cascade: 1 tuple(s) of fkeys are deleted
NOTICE: check_pkeys_fkey_cascade: 1 tuple(s) of fkeys2 are deleted
DROP TABLE pkeys;
+ ERROR: cache lookup of relation 129432 failed
DROP TABLE fkeys;
DROP TABLE fkeys2;
-- -- I've disabled the funny_dup17 test because the new semantics
==
*** ./expected/sanity_check.out Mon Aug 19 13:33:36 2002
--- ./results/sanity_check.out Sat Jul 26 20:10:20 2003
***
*** 58,68
pg_statistic| t
pg_trigger | t
pg_type | t
road| t
shighway| t
tenk1 | t
tenk2 | t
! (52 rows)
--
-- another sanity check: every system catalog that has OIDs should
have--- 58,69
pg_statistic| t
pg_trigger | t
pg_type | t
+ pkeys | t
road| t
shighway| t
tenk1 | t
tenk2 | t
! (53 rows)
--
-- another sanity check: every system catalog that has OIDs should
have
==
*** ./expected/misc.out Sat Jul 26 20:03:48 2003
--- ./results/misc.out Sat Jul 26 20:10:22 2003
***
*** 633,638
--- 633,639
onek2
path_tbl
person
+ pkeys
point_tbl
polygon_tbl
ramp
***
*** 657,663
toyemp
varchar_tbl
xacttest
! (93 rows)
--SELECT name(equipment(hobby_construct(text 'skywalking', text
'mer'))) AS equip_name; SELECT hobbies_by_name('basketball');
--- 658,664
toyemp
varchar_tbl
xacttest
! (94 rows)
--SELECT name(equipment(hobby_construct(text 'skywalking', text
'mer'))) AS equip_name; SELECT hobbies_by_name('basketball');
==
--
20:11:31 up 9 days, 12 min, 2 users, load average: 2.86, 2.30, 1.52
pgp0.pgp
Description: PGP signature
Re: [HACKERS] parallel regression test failure
On Fri, 25 Jul 2003 19:57:04 -0400
Tom Lane [EMAIL PROTECTED] said something like:
Bruce Momjian [EMAIL PROTECTED] writes:
I am seeing the following parallel regression test failures. Any
idea on the cause?
I don't see it here, on either of two different architectures. Maybe
you need a make distclean and rebuild?
I was just able to get some problems on my dual Athlon machine
(after about 10 runs) with a clean cvs download.
Linux thunder.mshome.net 2.4.21-0.13_test #35 SMP Wed Apr 9 07:29:10 MDT
2003 i686 unknown unknown GNU/Linux
gcc (GCC) 3.2.2 (Mandrake Linux 9.1 3.2.2-3mdk)
./configure --with-pgport=5433 --prefix=/usr/local/pgsql_cvs
sh src/tools/pgtest
sh src/tools/pgtest -n
*** ./expected/triggers.out Thu Jul 24 11:52:50 2003
--- ./results/triggers.out Fri Jul 25 21:20:34 2003
***
*** 92,97
--- 92,98
DROP TABLE pkeys;
DROP TABLE fkeys;
DROP TABLE fkeys2;
+ ERROR: could not open relation with OID 119498
-- -- I've disabled the funny_dup17 test because the new semantics
-- -- of AFTER ROW triggers, which get now fired at the end of a
-- -- query always, cause funny_dup17 to enter an endless loop.
==
*** ./expected/sanity_check.out Wed May 28 10:04:02 2003
--- ./results/sanity_check.out Fri Jul 25 21:20:37 2003
***
*** 15,20
--- 15,21
bt_name_heap| t
bt_txt_heap | t
fast_emp4000| t
+ fkeys2 | t
func_index_heap | t
hash_f8_heap| t
hash_i4_heap| t
***
*** 62,68
shighway| t
tenk1 | t
tenk2 | t
! (52 rows)
--
-- another sanity check: every system catalog that has OIDs should
have--- 63,69
shighway| t
tenk1 | t
tenk2 | t
! (53 rows)
--
-- another sanity check: every system catalog that has OIDs should
have
==
*** ./expected/misc.out Fri Jul 25 21:14:51 2003
--- ./results/misc.out Fri Jul 25 21:20:39 2003
***
*** 598,603
--- 598,604
equipment_r
f_star
fast_emp4000
+ fkeys2
float4_tbl
float8_tbl
func_index_heap
***
*** 660,666
toyemp
varchar_tbl
xacttest
! (96 rows)
--SELECT name(equipment(hobby_construct(text 'skywalking', text
'mer'))) AS equip_name; SELECT hobbies_by_name('basketball');
--- 661,667
toyemp
varchar_tbl
xacttest
! (97 rows)
--SELECT name(equipment(hobby_construct(text 'skywalking', text
'mer'))) AS equip_name; SELECT hobbies_by_name('basketball');
==
--
21:23:44 up 8 days, 1:24, 2 users, load average: 0.11, 1.04, 1.31
pgp0.pgp
Description: PGP signature
Re: [HACKERS] parallel regression test failure
On Fri, 25 Jul 2003 19:57:04 -0400 Tom Lane [EMAIL PROTECTED] said something like: Bruce Momjian [EMAIL PROTECTED] writes: I am seeing the following parallel regression test failures. Any idea on the cause? I don't see it here, on either of two different architectures. Maybe you need a make distclean and rebuild? And another failure: *** ./expected/constraints.out Fri Jul 25 21:14:51 2003 --- ./results/constraints.out Fri Jul 25 21:34:09 2003 *** *** 212,244 DROP SEQUENCE INSERT_SEQ; CREATE SEQUENCE INSERT_SEQ START 4; CREATE TABLE tmp (xd INT, yd TEXT, zd INT); INSERT INTO tmp VALUES (null, 'Y', null); INSERT INTO tmp VALUES (5, '!check failed', null); INSERT INTO tmp VALUES (null, 'try again', null); INSERT INTO INSERT_TBL(y) select yd from tmp; SELECT '' AS three, * FROM INSERT_TBL; three | x | y | z ! ---+---+---+ !| 4 | Y | -4 !| 5 | !check failed | -5 !| 6 | try again | -6 ! (3 rows) INSERT INTO INSERT_TBL SELECT * FROM tmp WHERE yd = 'try again'; INSERT INTO INSERT_TBL(y,z) SELECT yd, -7 FROM tmp WHERE yd = 'try again'; INSERT INTO INSERT_TBL(y,z) SELECT yd, -8 FROM tmp WHERE yd = 'try again';! ERROR: new row for relation insert_tbl violates CHECK constraint insert_con SELECT '' AS four, * FROM INSERT_TBL; four | x | y | z ! --+---+---+ ! | 4 | Y | -4 ! | 5 | !check failed | -5 ! | 6 | try again | -6 ! | | try again | ! | 7 | try again | -7 ! (5 rows) DROP TABLE tmp; -- -- Check constraints on UPDATE -- --- 212,244 DROP SEQUENCE INSERT_SEQ; CREATE SEQUENCE INSERT_SEQ START 4; CREATE TABLE tmp (xd INT, yd TEXT, zd INT); + ERROR: relation 126260 deleted while still in use INSERT INTO tmp VALUES (null, 'Y', null); + ERROR: relation tmp does not exist INSERT INTO tmp VALUES (5, '!check failed', null); + ERROR: relation tmp does not exist INSERT INTO tmp VALUES (null, 'try again', null); + ERROR: relation tmp does not exist INSERT INTO INSERT_TBL(y) select yd from tmp; + ERROR: relation tmp does not exist SELECT '' AS three, * FROM INSERT_TBL; three | x | y | z ! ---+---+---+--- ! (0 rows) INSERT INTO INSERT_TBL SELECT * FROM tmp WHERE yd = 'try again'; + ERROR: relation tmp does not exist INSERT INTO INSERT_TBL(y,z) SELECT yd, -7 FROM tmp WHERE yd = 'try again';+ ERROR: relation tmp does not exist INSERT INTO INSERT_TBL(y,z) SELECT yd, -8 FROM tmp WHERE yd = 'try again';! ERROR: relation tmp does not exist SELECT '' AS four, * FROM INSERT_TBL; four | x | y | z ! --+---+---+--- ! (0 rows) DROP TABLE tmp; + ERROR: table tmp does not exist -- -- Check constraints on UPDATE -- *** *** 246,261 UPDATE INSERT_TBL SET x = 6 WHERE x = 6; UPDATE INSERT_TBL SET x = -z, z = -x; UPDATE INSERT_TBL SET x = z, z = x; - ERROR: new row for relation insert_tbl violates CHECK constraint insert_con SELECT * FROM INSERT_TBL; x | y | z ! ---+---+ ! 4 | Y | -4 !| try again | ! 7 | try again | -7 ! 5 | !check failed | ! 6 | try again | -6 ! (5 rows) -- DROP TABLE INSERT_TBL; -- --- 246,255 UPDATE INSERT_TBL SET x = 6 WHERE x = 6; UPDATE INSERT_TBL SET x = -z, z = -x; UPDATE INSERT_TBL SET x = z, z = x; SELECT * FROM INSERT_TBL; x | y | z ! ---+---+--- ! (0 rows) -- DROP TABLE INSERT_TBL; -- == -- 21:34:48 up 8 days, 1:35, 2 users, load average: 0.89, 0.65, 0.85 pgp0.pgp Description: PGP signature
