From: Tom Lane <tgl@sss.pgh.pa.us>
To: Will Hartung <willhartung@gmail.com>
cc: pgsql-general@lists.postgresql.org
Subject: Re: Loading table with indexed jsonb field is stalling
In-reply-to: 
 <CAKMEDdxE95SC76wadMzrH454HpvCV4tOdEmuZRO=pwArEw6YVg@mail.gmail.com>
References: 
 <CAKMEDdxE95SC76wadMzrH454HpvCV4tOdEmuZRO=pwArEw6YVg@mail.gmail.com>
Comments: In-reply-to Will Hartung <willhartung@gmail.com>
	message dated "Fri, 17 May 2019 12:10:24 -0700"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <20504.1558202555.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Sat, 18 May 2019 14:02:35 -0400
Message-ID: <20505.1558202555@sss.pgh.pa.us>
Precedence: bulk

Will Hartung <willhartung@gmail.com> writes:
> I am trying to load data in to a table with a jsonb field that is indexe=
d
> as gin (field jsonb_path_ops).
> ...
> The current file is "stuck", pushing past 20hrs so far.

In addition to the questions about what PG version you're using, is
the backend process that's doing the load actually consuming CPU time,
or is it just sitting?

If the latter, I wonder whether you're seeing the deadlock against
VACUUM that was fixed a few months ago.  A similarly-stuck vacuum
or autovacuum process would be pretty conclusive ...

Author: Alexander Korotkov <akorotkov@postgresql.org>
Branch: master [fd83c83d0] 2018-12-13 06:55:34 +0300
Branch: REL_11_STABLE Release: REL_11_2 [9aa94d853] 2018-12-13 06:15:23 +0=
300
Branch: REL_10_STABLE Release: REL_10_7 [2e3bd064e] 2018-12-13 06:22:39 +0=
300

    Fix deadlock in GIN vacuum introduced by 218f51584d5
    =

    Before 218f51584d5 if posting tree page is about to be deleted, then t=
he whole
    posting tree is locked by LockBufferForCleanup() on root preventing al=
l the
    concurrent inserts.  218f51584d5 reduced locking to the subtree contai=
ning
    page to be deleted.  However, due to concurrent parent split, inserter=
 doesn't
    always holds pins on all the pages constituting path from root to the =
target
    leaf page.  That could cause a deadlock between GIN vacuum process and=
 GIN
    inserter.  And we didn't find non-invasive way to fix this.
    =

    This commit reverts VACUUM behavior to lock the whole posting tree bef=
ore
    delete any page.  However, we keep another useful change by 218f51584d=
5: the
    tree is locked only if there are pages to be deleted.

			regards, tom lane