On Sun, Feb 20, 2011 at 12:39 PM, Greg Stark <gsst...@mit.edu> wrote: > On Fri, Feb 18, 2011 at 6:59 PM, Andrew Dunstan <amduns...@nc.rr.com> wrote: >> The server is running as a warm standby, and the client's application tries >> to connect to both the master and the slave, accepting whichever lets it >> connect (hence hot standby is not turned on). >>... >> #2 0x00000000005de645 in LockBufferForCleanup () at bufmgr.c:2432 >> #3 0x0000000000463733 in heap_xlog_clean (lsn=<value optimized out>, > > Hm, if hot standby isn't turned on why are we bothering with locks at > all? But that said is there *anything* else happening in the database > aside from recovery? Are there any errors in the database log? > > But this still shouldn't block. It's either blocked locking the buffer > or blocked waiting for the buffer to become unpinned. It would be nice > to get a backtrace from a debugging build which wouldn't have some of > the functions inlined. It would be really nice to see the pin count on > the buffer in question -- perhaps it has gotten out of sync or > underflowed?
I realize now that it would also be useful to see the state of the LWLock on the buffer. A little OT, but ISTM that the buffer pin mechanism by its nature is prone to lock upgrade hazards. A cleanup lock is essentially an access exclusive lock on the buffer, while a buffer pin is an access share lock. In the middle, we have the usual share and exclusive (content) locks. We regularly try to upgrade buffer pins to any of the higher locking levels, which is quite unlike what we do with regular (heavyweight) locks, where we take some pains to avoid lock upgrades. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers