Re: 8.3.0 Core with concurrent vacuum fulls

"Gavin M. Roy" <gmr@myyearbook.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