Re: BUG #13559: WAL replay stuck after DROP VIEW
От | Greg Stark |
---|---|
Тема | Re: BUG #13559: WAL replay stuck after DROP VIEW |
Дата | |
Msg-id | CAM-w4HPCM7oi3rFUy7vm7f49uZ4Etz+K9tbUjYs7ZGM9ekLx-g@mail.gmail.com обсуждение исходный текст |
Ответ на | BUG #13559: WAL replay stuck after DROP VIEW (maciek@heroku.com) |
Ответы |
Re: BUG #13559: WAL replay stuck after DROP VIEW
|
Список | pgsql-bugs |
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
В списке pgsql-bugs по дате отправления: