Re: pgsql: Compute XID horizon for page level index vacuum on primary.

On 2019-03-28 17:34:52 +1300, Thomas Munro wrote:
> On Wed, Mar 27, 2019 at 1:06 PM Andres Freund <andres(at)anarazel(dot)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