BUG #13559: WAL replay stuck after DROP VIEW - Mailing list pgsql-bugs

From maciek@heroku.com
Subject BUG #13559: WAL replay stuck after DROP VIEW
Date
Msg-id 20150810223114.2696.65707@wrigleys.postgresql.org
Whole thread Raw
Responses Re: BUG #13559: WAL replay stuck after DROP VIEW  (Michael Paquier <michael.paquier@gmail.com>)
Re: BUG #13559: WAL replay stuck after DROP VIEW  (Greg Stark <stark@mit.edu>)
List 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 by date:

Previous
From: Dmitri Bourlatchkov
Date:
Subject: Re: PostgreSQL 9.4.4 Solaris 10 i386 download links point to Sparc binaries
Next
From: ismaelbezerra@gmail.com
Date:
Subject: BUG #13558: PANIC: stuck spinlock