=0A=
> From: tgl@sss.pgh.pa.us=0A=
> To: johnlumby@hotmail.com=0A=
> CC: pgsql-bugs@postgresql.org=0A=
> Subject: Re: [BUGS] Re: BUG #14098: misleading message "out of shared mem=
ory" when lock table space exhausted=0A=
> Date: Tue=2C 19 Apr 2016 12:42:47 -0400=0A=
>=0A=
> John Lumby <johnlumby@hotmail.com> writes:=0A=
>> Firstly=2C the documentation (Server Configuration=2C Lock Management) i=
s very clear :=0A=
>=0A=
> You're mistaking a guarantee for a hard limit.=0A=
>=0A=
> What actually happens is that enough shared memory is reserved for at=0A=
> least max_locks_per_transaction * (max_connections +=0A=
> max_prepared_transactions) lock entries=2C plus a bunch of unrelated stuf=
f=2C=0A=
=0A=
I see =2C=A0 thanks for explaining.=0A=
=0A=
> I'm not sure if that documentation wording needs improvement or not.=0A=
=0A=
On reflection=2C=A0 I would still suggest to change the wording of the erro=
r message=2C=0A=
not the documentation.=0A=
=0A=
I now see that as you've explained=2C=A0 the words =A0=A0=A0=A0 =0A=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 out of shared memory=0A=
are not wrong.=A0=A0 However=2C=A0=A0 I think it may be more helpful to cha=
nge them to=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =0A=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 lock table space is exhausted=0A=
as I previously suggested.=0A=
The reason being that =2C=A0 for most people=2C=A0 intuitively=2C=A0 tellin=
g them=0A=
=A0=A0=A0 " out of shared memory "=0A=
would indicate to try to *reduce* the consumption of this resource=2C=0A=
whereas the hint tells them=A0 to *increase* something.=0A=
I think there is a clearer connection between insufficient lock table space=
=0A=
and increasing max_locks_per_transaction.=0A=
=0A=
The documentation is also not wrong but it is conservative=0A=
and leads to the admin doing the right thing=2C=0A=
so I would leave that as is.=0A=
=0A=
Cheers=2C=A0=A0 John=0A=
=0A=
> regards=2C tom lane=0A=
=