| From: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
|---|---|
| To: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
| Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Hot Standby remaining issues |
| Date: | 2009-12-02 11:16:36 |
| Message-ID: | 4B164C94.4050600@enterprisedb.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Simon Riggs wrote:
> On Wed, 2009-12-02 at 12:49 +0200, Heikki Linnakangas wrote:
>
>> If a read-only transaction holds a lot of locks, consuming so much
>> lock space that there's none left for the startup process to hold the
>> lock it wants, it will abort and bring down postmaster. The patch
>> attempts to kill any conflicting lockers, but those are handled fine
>> already (if there's any conflicting locks, LockAcquire will return
>> LOCKACQUIRE_NOT_AVAIL anyway). The problem is with non-conflicting
>> locks using up the lock space.
>
> Oh dear, another "nuke 'em all from orbit" scenario. Will do.
Yeah. This case is much like the OOM killer on Linux. Not really "nuke
'em all" but "nuke someone, don't care who"..
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Dimitri Fontaine | 2009-12-02 11:26:39 | Re: Page-level version upgrade |
| Previous Message | Laurent Laborde | 2009-12-02 11:13:35 | Re: Cost of sort/order by not estimated by the query planner |