Re: Re: BUG #14098: misleading message "out of shared memory" when lock table space exhausted
От | John Lumby |
---|---|
Тема | Re: Re: BUG #14098: misleading message "out of shared memory" when lock table space exhausted |
Дата | |
Msg-id | COL131-W405057C2F06E60349A8B33A36C0@phx.gbl обсуждение исходный текст |
Ответ на | Re: Re: BUG #14098: misleading message "out of shared memory" when lock table space exhausted (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Re: BUG #14098: misleading message "out of shared
memory" when lock table space exhausted
|
Список | pgsql-bugs |
=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= =
В списке pgsql-bugs по дате отправления: