From: | Andres Freund <andres(at)2ndquadrant(dot)com> |
---|---|
To: | Greg Stark <stark(at)mit(dot)edu> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Deadlocks in HS (on 9.0 :( ) |
Date: | 2014-07-16 08:00:32 |
Message-ID: | 20140716080032.GF22721@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2014-07-15 16:54:05 +0100, Greg Stark wrote:
> We've observed a 9.0 database have undetected deadlocks repeatedly in
> hot standby mode.
>
> I think what's happening is that autovacuum is kicking off a VACUUM of
> some system catalogs -- it seems to usually be pg_statistics' toast
> table actually. At the end of the vacuum it briefly gets the exclusive
> lock to truncate the table. On the standby it replays that and records
> the exclusive lock being taken. It then sees a cleanup record that
> pauses replay because a HS standby transaction is running that can see
> the xid being cleaned up. That transaction then blocks against the
> exclusive lock and deadlocks against recovery.
Hm. Does that resolve itself after max_standby_streaming_delay? Because
I don't really see how it'd actually have an undetected deadlock in that
case.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Petr Jelinek | 2014-07-16 08:04:13 | Re: Built-in binning functions |
Previous Message | Magnus Hagander | 2014-07-16 06:43:25 | Re: TODO : Allow parallel cores to be used by vacuumdb [ WIP ] |