From: | Greg Stark <stark(at)mit(dot)edu> |
---|---|
To: | Maciek Sakrejda <maciek(at)heroku(dot)com> |
Cc: | PostgreSQL Bugs <pgsql-bugs(at)postgresql(dot)org> |
Subject: | Re: BUG #13559: WAL replay stuck after DROP VIEW |
Date: | 2015-08-13 22:50:05 |
Message-ID: | CAM-w4HPCM7oi3rFUy7vm7f49uZ4Etz+K9tbUjYs7ZGM9ekLx-g@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Mon, Aug 10, 2015 at 11:31 PM, <maciek(at)heroku(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | zhangjinyu | 2015-08-14 11:45:34 | Re: BUG #13541: There is a visibility issue when run some DDL and Query. The time window is very shot |
Previous Message | Noah Misch | 2015-08-12 05:57:19 | Re: BUG #13427: postgres.exe fails to start on Korean Windows Server 2008: cannot perform encoding conversion outsid |