From: Tom Lane <tgl@sss.pgh.pa.us>
To: Ian Dick <ian.dick01@gmail.com>
cc: pgsql-general@postgresql.org
Subject: Re: Some questions about CREATE INDEX CONCURRENTLY and pg_advisory_lock
In-reply-to: <CAJYceS5Kmgd9uxUkb8EfDiATbiVURsCcpW8=stjP+LJ_hoJ+RA@mail.gmail.com>
References: <CAJYceS5Kmgd9uxUkb8EfDiATbiVURsCcpW8=stjP+LJ_hoJ+RA@mail.gmail.com>
Comments: In-reply-to Ian Dick <ian.dick01@gmail.com>
	message dated "Wed, 24 Dec 2025 22:26:26 +1100"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1630376.1766808207.1@sss.pgh.pa.us>
Date: Fri, 26 Dec 2025 23:03:27 -0500
Message-ID: <1630377.1766808207@sss.pgh.pa.us>
Archived-At: <https://www.postgresql.org/message-id/1630377.1766808207%40sss.pgh.pa.us>
Precedence: bulk

Ian Dick <ian.dick01@gmail.com> writes:
> I recently noticed some behaviour regarding the CREATE INDEX CONCURRENTLY
> operation, combined with pg_advisory_lock, which I found surprising. I've
> looked online for a specific explanation of what's happening, but couldn't
> seem to find a concrete explanation for what I'm seeing.

You did find the explanation:

> the 2nd phase of the index creation needs to wait until all current
> transaction with a snapshot preceding index creation have finished:
> "After the second scan, the index build must wait for any transactions that
> have a snapshot (see Chapter 13
> <https://www.postgresql.org/docs/current/mvcc.html>) predating the second
> scan to terminate"

The blocked "SELECT pg_advisory_lock" doesn't hold any interesting
locks, but nonetheless it has a snapshot.

> I'm also curious if it might be possible to patch the code to
> ignore txns like this which should not interfere with the index creation.

Doubt it.  You may know that the blocked transaction will not later
try to touch the table being indexed, but Postgres can't really know
that, especially not from within a different session.

			regards, tom lane