=0A=
> Date: Tue=2C 19 Apr 2016 12:48:55 -0700=0A=
> From: daveg@sonic.net=0A=
> To: johnlumby@hotmail.com=0A=
> CC: tgl@sss.pgh.pa.us=3B pgsql-bugs@postgresql.org=0A=
> Subject: Re: [BUGS] Re: BUG #14098: misleading message "out of shared mem=
ory" when lock table space exhausted=0A=
>=0A=
> On Tue=2C 19 Apr 2016 13:36:35 -0400=0A=
> John Lumby <johnlumby@hotmail.com> wrote:=0A=
>=0A=
>=0A=
>> I now see that as you've explained=2C the words=0A=
>> out of shared memory=0A=
>> are not wrong. However=2C I think it may be more helpful to change t=
hem to=0A=
>> lock table space is exhausted=0A=
>> as I previously suggested.=0A=
>=0A=
> There are reasons besides locks that can lead to consuming all the alloca=
ted=0A=
> shared memory. A message that specifically blamed locks would actively mi=
slead=0A=
> a user who was trying to diagnose one of the less common cases.=0A=
=0A=
That may well be true=2C=A0 but in my original bug report I specifically si=
ngled out =0A=
messages originating from the lock manager which are in fact referring to a=
failure =0A=
to allocate space for a new lock=A0 :=0A=
=0A=
from earlier posting :=0A=
_______________________________________________________=0A=
If postgresql exhausts the space reserved for locks=2C=0A=
whose size is defined by =0A=
max_locks_per_transaction *=0A=
=A0(max_connections + max_prepared_transactions)=0A=
locks=2C then it issues this message :=0A=
=0A=
psql: FATAL: out of shared memory=0A=
HINT: You might need to increase max_locks_per_transaction.[ ... ]=0A=
=0A=
I believe all cases of this msg are in=0A=
src/backend/storage/lmgr/lock.c___________________________________________=
____________=0A=
Perhaps in view of your comment I should reword this as :=0A=
=0A=
whenever lock manager issues a message relating to failure to=0A=
allocate space for a lock =2C then [ suggestion as before ]=0A=
=0A=
>=0A=
> -dg=0A=
>=0A=
> --=0A=
> David Gould daveg@sonic.net=0A=
=0A=
=