Re: Hot standby, recent changes

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Hot standby, recent changes
Date: 2009-12-06 11:20:50
Message-ID: 1260098450.13774.44508.camel@ebony
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2009-12-06 11:54:20 Re: Cancelling idle in transaction state
Previous Message Kurt Harriman 2009-12-06 11:20:10 Re: Patch: Remove gcc dependency in definition of inline functions