Re: Hot standby, recent changes - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: Hot standby, recent changes
Date
Msg-id 1260098450.13774.44508.camel@ebony
Whole thread Raw
In response to Hot standby, recent changes  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Responses Re: Hot standby, recent changes  (Simon Riggs <simon@2ndQuadrant.com>)
List pgsql-hackers
On Sun, 2009-12-06 at 12:32 +0200, Heikki Linnakangas wrote:

> 3. The "Out of lock mem killer" in StandbyAcquireAccessExclusiveLock is
> quite harsh. It aborts all read-only transactions. It should be enough
> to kill just one random one, or maybe the one that's holding most locks.
> Also, if there still isn't enough shared memory after killing all
> backends, it goes into an infinite loop. I guess that shouldn't happen,
> but it seems a bit squishy anyway. It would be nice to differentiate
> between "out of shared mem" and "someone else is holding the lock" more
> accurately. Maybe add a new return value to LockAcquire() for "out of
> shared mem".

OK, will abort infinite loop by adding new return value.

If people don't like having everything killed, they can add more lock
memory. It isn't worth adding more code because its hard to test and
unlikely to be an issue in real usage, and it has a clear workaround
that is already mentioned in a hint.

-- Simon Riggs           www.2ndQuadrant.com



pgsql-hackers by date:

Previous
From: Kurt Harriman
Date:
Subject: Re: Patch: Remove gcc dependency in definition of inline functions
Next
From: Robert Haas
Date:
Subject: Re: Cancelling idle in transaction state