BUG #13559: WAL replay stuck after DROP VIEW

From: maciek(at)heroku(dot)com
To: pgsql-bugs(at)postgresql(dot)org
Subject: BUG #13559: WAL replay stuck after DROP VIEW
Date: 2015-08-10 22:31:14
Message-ID: 20150810223114.2696.65707@wrigleys.postgresql.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

The following bug has been logged on the website:

Bug reference: 13559
Logged by: Maciek Sakrejda
Email address: maciek(at)heroku(dot)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.

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Michael Paquier 2015-08-11 03:18:05 Re: BUG #13559: WAL replay stuck after DROP VIEW
Previous Message ismaelbezerra 2015-08-10 20:43:19 BUG #13558: PANIC: stuck spinlock