Re: 8.3.0 Core with concurrent vacuum fulls

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 <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> "Gavin M. Roy" <gmr(at)myyearbook(dot)com> 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
>