2008-03-04 05:45:47 EST [6698]: [1-1] LOG: process 6698 still waiting for AccessShareLock on relation 1247 of database 16385 after 1001.519 ms 2008-03-04 05:45:47 EST [6698]: [2-1] STATEMENT: VACUUM FULL autograph.autograph_creators 2008-03-04 05:46:28 EST [6730]: [1-1] LOG: process 6730 still waiting for AccessShareLock on relation 1247 of database 16385 after 1000.887 ms 2008-03-04 05:46:28 EST [6730]: [2-1] STATEMENT: VACUUM FULL lunchmoney.totals 2008-03-04 05:47:55 EST [3809]: [18-1] LOG: server process (PID 6742) was terminated by signal 6: Aborted 2008-03-04 05:47:55 EST [3809]: [19-1] LOG: terminating any other active server processes 2008-03-04 05:47:55 EST [6741]: [12-1] WARNING: terminating connection because of crash of another server process
On Tue, Mar 4, 2008 at 9:56 PM, Tom Lane <[EMAIL PROTECTED]> wrote: > "Gavin M. Roy" <[EMAIL PROTECTED]> writes: > > (gdb) where > > #0 0x0000003fe362e21d in raise () from /lib64/tls/libc.so.6 > > #1 0x0000003fe362fa1e in abort () from /lib64/tls/libc.so.6 > > #2 0x000000000063a2e3 in errfinish () > > #3 0x00000000005974c4 in DeadLockReport () > > #4 0x000000000059381f in LockAcquire () > > #5 0x0000000000592357 in LockRelationOid () > > #6 0x0000000000457255 in relation_open () > > #7 0x00000000004574c3 in heap_open () > > #8 0x000000000062cf41 in CatalogCacheInitializeCache () > > #9 0x000000000062dfad in PrepareToInvalidateCacheTuple () > > #10 0x000000000062e8c5 in CacheInvalidateHeapTuple () > > #11 0x000000000045c803 in heap_page_prune () > > #12 0x00000000005086cd in vacuum_rel () > > #13 0x00000000005096bb in vacuum () > > #14 0x00000000005a163b in PortalRunUtility () > > #15 0x00000000005a1714 in PortalRunMulti () > > #16 0x00000000005a1d30 in PortalRun () > > #17 0x000000000059f4b6 in PostgresMain () > > #18 0x00000000005760c0 in ServerLoop () > > #19 0x0000000000577770 in PostmasterMain () > > #20 0x000000000052fd3e in main () > > So what did DeadLockReport put in the server log before panic'ing? > > I'm wondering exactly why CatalogCacheInitializeCache is being called > here --- seems like that should have been done long before we got to > VACUUM. But it would be useful to know just what deadlock it saw. > > regards, tom lane >
