MIME-Version: 1.0
References: 
 <CAHg+QDfdoR=7iqEAvLW9qtzV0Sx1wp2FuALeamqcCdiVEmMF-Q@mail.gmail.com>
In-Reply-To: 
 <CAHg+QDfdoR=7iqEAvLW9qtzV0Sx1wp2FuALeamqcCdiVEmMF-Q@mail.gmail.com>
From: Ashutosh Sharma <ashu.coek88@gmail.com>
Date: Mon, 30 Mar 2026 16:41:08 +0530
Message-ID: 
 <CAE9k0PkMrtBoC-0-2xBKpLXiBMM684HMpw1Sqo9sXaeECriEvg@mail.gmail.com>
Subject: Re: Make pg_prewarm, autoprewarm yield for waiting DDL
To: SATYANARAYANA NARLAPURAM <satyanarlapuram@gmail.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CAE9k0PkMrtBoC-0-2xBKpLXiBMM684HMpw1Sqo9sXaeECriEvg%40mail.gmail.com>
Precedence: bulk

Hi Satya,

On Thu, Mar 26, 2026 at 3:02=E2=80=AFAM SATYANARAYANA NARLAPURAM
<satyanarlapuram@gmail.com> wrote:
>
> Both pg_prewarm() and the autoprewarm background worker hold AccessShareL=
ock on the target relation for the entire duration of prewarming. On large =
tables this can take a long time, which means
> that any DDL that needs a stronger lock (TRUNCATE, DROP TABLE, ALTER TABL=
E, etc.) is blocked for the full duration.
>

This indeed seems like a valid concern.

> VACUUM already solves this same problem during heap truncation: it period=
ically calls LockHasWaitersRelation() and backs off when a conflicting wait=
er is detected (see lazy_truncate_heap()).
>

Yes, in the current design, waiter-aware backoff logic is present in
some code paths (like VACUUM) that acquire the strongest lock
(AccessExclusiveLock), but is largely absent from paths that hold
weaker locks.

While AccessShareLock conflicts with only one lock mode
(AccessExclusiveLock), a long-held AccessShareLock, as in the
pg_prewarm case you mentioned, can still cause meaningful delays for
DDL or maintenance operations that require AccessExclusiveLock. So
despite its narrow conflict set, the practical impact can be quite
significant in some cases. On that basis, extending waiter-aware
behavior to places like pg_prewarm (or similar long-running lock
holders) seems reasonable, though it would be worth seeing how others
think about it.

--
With Regards,
Ashutosh Sharma.