On 2019-03-28 17:34:52 +1300, Thomas Munro wrote: > On Wed, Mar 27, 2019 at 1:06 PM Andres Freund <and...@anarazel.de> wrote: > > Compute XID horizon for page level index vacuum on primary. > > Hi Andres, > > I have a virtual machine running FreeBSD 12.0 on i386 on which > contrib/test_decoding consistently self-deadlocks in the "rewrite" > test, with the stack listed below. You can see that we wait for a > share lock that we already hold exclusively. Peter Geoghegan spotted > the problem: this code path shouldn't access syscache, or at least not > for a catalog table. He suggested something along these lines: > > --- a/src/backend/access/heap/heapam.c > +++ b/src/backend/access/heap/heapam.c > @@ -6977,7 +6977,10 @@ heap_compute_xid_horizon_for_tuples(Relation rel, > * simplistic, but at the moment there is no evidence of that > or any idea > * about what would work better. > */ > - io_concurrency = > get_tablespace_io_concurrency(rel->rd_rel->reltablespace); > + if (IsCatalogRelation(rel)) > + io_concurrency = 1; > + else > + io_concurrency = > get_tablespace_io_concurrency(rel->rd_rel->reltablespace); > prefetch_distance = Min((io_concurrency) + 10, MAX_IO_CONCURRENCY);
Hm, good catch. I don't like this fix very much (even if it were commented), but I don't have a great idea right now. I'm mildly inclined to take effective_io_concurrency into account even if we can't use get_tablespace_io_concurrency - that should be doable from a locking POV. Do you want to apply the above? - Andres
