Re: Re: BUG #14098: misleading message "out of shared memory" when lock table space exhausted

On Tue, 19 Apr 2016 13:36:35 -0400
John Lumby <johnlumby@hotmail.com> wrote:


> I now see that as you've explained,=C2=A0 the words =C2=A0=C2=A0=C2=A0=C2=
=A0=20
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 out of=
 shared memory
> are not wrong.=C2=A0=C2=A0 However,=C2=A0=C2=A0 I think it may be more he=
lpful to change them to=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=20
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 lock table s=
pace is exhausted
> as I previously suggested.
> The reason being that ,=C2=A0 for most people,=C2=A0 intuitively,=C2=A0 t=
elling them
> =C2=A0=C2=A0=C2=A0 " out of shared memory "
> would indicate to try to *reduce* the consumption of this resource,
> whereas the hint tells them=C2=A0 to *increase* something.
> I think there is a clearer connection between insufficient lock table spa=
ce=20
> and increasing max_locks_per_transaction.

There are reasons besides locks that can lead to consuming all the allocated
shared memory. A message that specifically blamed locks would actively misl=
ead
a user who was trying to diagnose one of the less common cases.

-dg


--=20
David Gould                                   daveg@sonic.net
If simplicity worked, the world would be overrun with insects.