Re: 8.3.0 Core with concurrent vacuum fulls

"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