BUG #13559: WAL replay stuck after DROP VIEW
От | maciek@heroku.com |
---|---|
Тема | BUG #13559: WAL replay stuck after DROP VIEW |
Дата | |
Msg-id | 20150810223114.2696.65707@wrigleys.postgresql.org обсуждение исходный текст |
Ответы |
Re: BUG #13559: WAL replay stuck after DROP VIEW
Re: BUG #13559: WAL replay stuck after DROP VIEW |
Список | pgsql-bugs |
The following bug has been logged on the website: Bug reference: 13559 Logged by: Maciek Sakrejda Email address: maciek@heroku.com PostgreSQL version: 9.4.1 Operating system: Ubuntu 12.04 Description: 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. We're on 9.4.1, but skimming through the 9.4.2-through-9.4.4 release notes, I don't see anything relevant. Could this be an outstanding bug? For what it's worth, we've been running the view drop / recreate for about 9 months, totalling probably ~240 drops / creates and this is the first time we've run into an issue.
В списке pgsql-bugs по дате отправления: