Re: 8.3.0 Core with concurrent vacuum fulls
| От | Gavin M. Roy |
|---|---|
| Тема | Re: 8.3.0 Core with concurrent vacuum fulls |
| Дата | |
| Msg-id | af1bce590803050709j5d597f3ck81dadc598e590a03@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: 8.3.0 Core with concurrent vacuum fulls (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: 8.3.0 Core with concurrent vacuum fulls
|
| Список | pgsql-hackers |
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@sss.pgh.pa.us> wrote:
"Gavin M. Roy" <gmr@myyearbook.com> writes:So what did DeadLockReport put in the server log before panic'ing?
> (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 ()
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
В списке pgsql-hackers по дате отправления: