On Wed, Mar 25, 2026 at 5:32 PM 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. > > 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()). > > The attached patch applies the same pattern to pg_prewarm and autoprewarm. > Every 1024 blocks, each code path checks for a waiter and if found then the > lock is released so that the DDL can proceed. Patch handles the relation > truncation, drop cases by emitting an error message. If the relation was only > partially truncated, the endpoint is adjusted downward and prewarming > continues. > When no DDL is waiting, the only overhead is one lock-table probe per 1024 > blocks.
This patch goes to quite a bit of trouble to restart prewarming of a relation after releasing and reacquiring the lock. I feel like that's adding a lot of complexity of questionable value. I think I'd be inclined not to change the foreground path at all, just like a foreground VACUUM doesn't do anything special to deprioritize itself, and make the autoprewarm give up on the relation entirely if someone else wants the lock, just like what autovacuum does. If we do it like this, I think we need a really good argument for handling this case differently from autovacuum. If somebody takes AccessExclusiveLock on a relation, there's a good chance that the block numbers we have are not even relevant any more afterwards. On a purely mechanical note, this patch results in a block of code in autoprewarm_database_main() that currently looks very simple looking extremely complicated instead. The purpose of that code is not so obvious any more, and there's a lot of extra indentation that impacts readability. If you want to pursue this, I suggest thinking about how you could introduce subroutines or otherwise refactor so that a future human reader will be able to understand this nearly as easily as they can understand the current code. -- Robert Haas EDB: http://www.enterprisedb.com
