From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: SR standby hangs |
Date: | 2011-02-18 19:33:48 |
Message-ID: | AANLkTimu=ZAFtsJfFMB7F=1qzVvTM+CJkyb8+sX5tQCm@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Feb 18, 2011 at 2:16 PM, Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
> I'm not quite sure where to start digging. Has anyone else seen
> something similar? Our consultant reports having seen a similar problem
> elsewhere, at a client who was running hot standby on 9.0.1, but the
> problem did not recur, as it does fairly regularly with this client.
I've seen a very similar backtrace that only involved one system (no
Hot Standby). The problem in that case appears to have been an open
cursor holding a buffer pin. LockBufferForCleanup() has logic that's
supposed to prevent that from going on too long during HS - it should
nuke the guy with the buffer in when the timeout expires - but maybe
there's a bug in that mechanism.
As a side matter, it would be good to improve this in the non-Hot
Standby case also. An open cursor can tie down an autovacuum worker
forever, which is not a good thing, as it's easily possible for the
number of open cursors to be larger than the number of available
autovacuum workers...
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2011-02-18 19:35:06 | Re: review: FDW API |
Previous Message | Bruce Momjian | 2011-02-18 19:33:14 | Re: pg_basebackup and wal streaming |