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

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