On Mon, Aug 10, 2015 at 11:31 PM, <maciek@heroku.com> wrote:
> We had some code in production that automatically dropped and recreated
> views periodically. This database also has a replica that serves some
> moderately intensive queries (read: on the order of several minutes). This
> generally this works fine, but we ran into an issue the other day where the
> startup process on the replica was holding a bunch of AccessExclusive locks
> on these views (presumably due to the DROP) and would not progress even
> though there were no conflicting queries (there may very well have been
> queries against these views at one point, but not not when I looked--all the
> locks held by the startup process showed up as granted in pg_locks). This
> resolved when we restarted the replica.
Is hot_standby_feedback enabled? Or vacuum_defer_cleanup_age set? Is
max_standby_*_delay set?
If all of these are off/zero then this sounds like the standby replays
an exclusive lock which blocks a query running in the standby, then
hits a vacuum record in the WAL log which it stops replay because the
blocked query has an old enough snapshot to see the record being
cleaned up.
--
greg