[BUGS] pg_dump bug?
I'm experiencing the same problem Mr. Dalphin was experiencing back in 1999: http://archives.postgresql.org/pgsql-bugs/1999-09/msg00056.php pg_dump does not dump functions used as column defaults before the definition of that table, so rebuilds fail. Has this bug been fixed, and I'm not seeing the pg_dump flag, or do I need to manually re-create such functions before executing the rebuild? I'm running PostgreSQL 7.3.4 on Solaris 9. Thanks, Erik G. Burrows ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [BUGS] PostgreSQL 7.4RC1 crashes on Panther
Scott Goodwin <[EMAIL PROTECTED]> writes: > psql:/Users/scott/m/ops/database/sql/add_languages.sql:13: server > closed the connection unexpectedly > This probably means the server terminated abnormally > before or while processing the request. > ...output in the log file is: > LOG: server process (PID 2739) was terminated by signal 10 Here's the real problem --- why are you getting a SIGBUS while trying to load the pltcl handler function? I suspect something broken in Tcl's shared library, but dunno what. You should be getting a core file from the crashed process --- can you get a stack trace from it with gdb? > FATAL: could not create shared memory segment: Cannot allocate memory > DETAIL: Failed system call was shmget(key=5432001, size=3809280, > 03600). This is evidently happening during attempted restart after the backend crash. I suspect it is a matter of the OS not having released the old memory segment yet, together with the SHMMAX limit being too tight to allow two such segments to exist concurrently. Are you able to start the server by hand immediately afterwards, or a few seconds afterwards? Or do you have to reboot before it will restart? regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [BUGS] PostgreSQL 7.4RC1 crashes on Panther
Scott Goodwin <[EMAIL PROTECTED]> writes: > After recompiling with GCC 3.1 it fails when I'm running initdb to > create the cluster -- it's a shmget error again. I believe that takes > both Tcl and PostgreSQL out of the suspect pool and leaves Mac OS 10.3 > as the primary culprit. Does the failure go away if you reboot? I'm wondering whether the conflicting shared memory segment is simply left over from your last failure. (Try "ipcs" if you have it; I don't think 10.2 did, but maybe Apple saw the light for 10.3.) We know that PG worked okay on 10.3 betas about a month back, so I'm doubtful that there's any serious problem in 10.3 final. Unfortunately I don't have a copy of 10.3 final yet to confirm ... regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] PostgreSQL 7.4RC1 crashes on Panther
Scott Goodwin <[EMAIL PROTECTED]> writes: > Just compiled PG 7.3.4 with GCC 3.1 on Panther and it exhibits the same > problem, but generates a SIGSEGV instead of a SIGBUS. I tried this on the 10.3 beta that I have (from about a month back) and indeed I get a core dump while trying to create the pltcl call handler. Steps to reproduce: configure --with-tcl --without-tk (no tk support?) make, make install, make installcheck are all ok createlang pltcl regression ... kaboom ... The stack trace looks like this: (gdb) bt #0 0x900f5fc0 in memcmp () #1 0x901c6734 in ?? () #2 0x8fe09c18 in __dyld_call_image_init_routines () #3 0x8fe11880 in __dyld_link_in_need_modules () #4 0x8fe134e4 in __dyld__dyld_link_module () #5 0x9003f5c8 in NSLinkModule () #6 0x00100f50 in pg_dlopen (filename=0x200d2c4 "/Users/tgl/testversion/lib/postgresql/pltcl.so") at dynloader.c:26 #7 0x001a1110 in load_external_function (filename=0xc01650 "", funcname=0x202b5a4 "pltcl_call_handler", signalNotFound=1 '\001', filehandle=0xbfffe344) at dfmgr.c:127 #8 0x00055c6c in fmgr_c_validator (fcinfo=0x0) at pg_proc.c:639 #9 0x001a3838 in OidFunctionCall1 (functionId=0, arg1=180982) at fmgr.c:1210 #10 0x000552bc in ProcedureCreate (procedureName=0xbfffe5f0 "", procNamespace=2200, replace=0 '\0', returnsSet=0 '\0', returnType=2280, languageObjectId=13, languageValidator=2247, prosrc=0x20234c0 "pltcl_call_handler", probin=0x20235b4 "$libdir/pltcl", isAgg=0 '\0', security_definer=0 '\0', isStrict=0 '\0', volatility=118 'v', parameterCount=0, parameterTypes=0xbfffe710) at pg_proc.c:331 #11 0x000880c0 in CreateFunction (stmt=0x234b3c) at functioncmds.c:515 ... But plpgsql works fine. Also, the same code works fine in OS X 10.2.*. Seems like either the Tcl shared library is broken in 10.3, or Apple broke something in the dynamic linker, or our dynamic-library-loading code is doing something that was OK with 10.2 but isn't OK with 10.3. I guess we need to call in some OS X experts ... Marko, can you take a look? BTW, the failure to restart after the crash is explained here: http://archives.postgresql.org/pgsql-hackers/2003-11/msg00321.php I'll have that fixed for 7.4, but I dunno what to do about pltcl's problem. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
