"Gavin M. Roy" <gmr@myyearbook.com> writes:
> 2008-03-04 05:45:20 EST [6742]: [7-1] PANIC: deadlock detected
> 2008-03-04 05:45:20 EST [6742]: [8-1] DETAIL: Process 6742 waits for
> AccessShareLock on relation 2619 of database 16385; blocked by process 6740.
> Process 6740 waits for AccessShareLock on relation 1247 of database 16385;
> blocked by process 6742.
> 2008-03-04 05:45:20 EST [6742]: [9-1] STATEMENT: VACUUM FULL
> pg_catalog.pg_type
Hmm ...
regression=# select 2619::regclass, 1247::regclass; regclass | regclass
--------------+----------pg_statistic | pg_type
(1 row)
regression=#
So presumably 6740 is doing a vac full on pg_statistic. There isn't
really any need for these to conflict in cache initialization.
It strikes me that we could fix most of the deadlock risk if we just
switched the order of the two tests in the loop in
PrepareToInvalidateCacheTuple; that is, don't force initialization
of a catcache unless it's one we need to access right now. Then a
VAC FULL is only going to be interested in initializing caches for
the catalog it's vacuuming, which should be safe enough.
We still need to deal with the excessive PANIC risk, but I think we
have a plan for that now.
regards, tom lane
