Hi Satya, On Thu, Mar 26, 2026 at 3:02 AM SATYANARAYANA NARLAPURAM <[email protected]> wrote: > > Both pg_prewarm() and the autoprewarm background worker hold AccessShareLock > 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 TABLE, > etc.) is blocked for the full duration. >
This indeed seems like a valid concern. > VACUUM already solves this same problem during heap truncation: it > periodically calls LockHasWaitersRelation() and backs off when a conflicting > waiter 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.
