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

=0A=
Thanks Tom=2C=0A=
=0A=
However Can you please explain a little more on this.=0A=
=0A=
Firstly=2C the documentation (Server Configuration=2C Lock Management) is v=
ery clear :=0A=
=0A=
_____________________________________________________=0A=
max_locks_per_transaction (integer)=0A=
=0A=
The shared lock table tracks locks on=0A=
max_locks_per_transaction * (max_connections + max_prepared_transactions) o=
bjects (e.g.=2C tables)=3B=0A=
=0A=
hence=2C *no more* than this many distinct objects can be locked at any one=
 time.=0A=
_____________________________________________________=0A=
=0A=
That apparently seems to support what I said and contradicts your assertion=
 -=0A=
depending on what you meant by "hard" separation.=0A=
=0A=
So if what you stated is correct=2C=A0 then two comments :=0A=
=0A=
=A0 .=A0=A0=A0 the documentation must be incorrect and should be corrected.=
=0A=
=A0 .=A0=A0=A0 can you please state exactly what is the limit for how many =
=0A=
=A0=A0=A0=A0=A0=A0 distinct objects can be locked at any one time=2C=A0 bas=
ed on configuration parameters.=0A=
=A0=A0=A0=A0=A0=A0 If this number can exceed max_locks_per_transaction * (m=
ax_connections + max_prepared_transactions)=2C=0A=
=A0=A0=A0=A0=A0=A0 then is this done by=0A=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 a) dynamically extending shared memory=0A=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 b) incursing into some other component's =
nominal portion of shared memory=2C=0A=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 (the amount it says it needs dur=
ing postgresql startup when the total size of the=0A=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 initial shared memory segment=
 is being computed)=0A=
=A0=A0=A0=A0=A0=A0 If b)=2C=A0 then can other components equally incurse in=
to the nominal lock table space?=0A=
=0A=
=0A=
=0A=
Cheers=2C John=0A=
=0A=
                           =