> The name max_locks_per_transaction indicates a limit of some kind. The
> documentation doesn't mention anything about whether that limit is
> enforced
> or not.
> 
> I suggest the additional wording:
> "This parameter is not a hard limit: No limit is enforced on the
number of
> locks in each transaction. System-wide, the total number of locks is
> limited
> by the size of the lock table."


I think it's worse than that.  First of all, user locks persist outside
of transactions, but they apply to this limit.  A more appropriate name
for the GUC variable would be 'estimated_lock_table_size_per_backend',
or something like that.  I've been putting some thought into reworking
the userlock contrib module into something acceptable into the main
project, a substantial part of that being documentation changes.

Merlin

Thu, 30 Sep 2004 08:09:30 -0400
"Merlin Moncure" <merlin.moncure@rcsonline.com>
Re: shared memory release following failed lock acquirement. 
> Merlin Moncure
> > The name max_locks_per_transaction indicates a limit of some kind. The
> > documentation doesn't mention anything about whether that limit is
> > enforced
> > or not.
> >
> > I suggest the additional wording:
> > "This parameter is not a hard limit: No limit is enforced on the
> number of
> > locks in each transaction. System-wide, the total number of locks is
> > limited
> > by the size of the lock table."
>
>
> I think it's worse than that.  First of all, user locks persist outside
> of transactions, but they apply to this limit.

I was really thinking of the standard locking case. Yes, user locks make it
worse.

> A more appropriate name
> for the GUC variable would be 'estimated_lock_table_size_per_backend',
> or something like that.  I've been putting some thought into reworking
> the userlock contrib module into something acceptable into the main
> project, a substantial part of that being documentation changes.
>

I agree a renamed parameter would be more appropriate, though I suspect a
more accurate name will be about 5 yards long.

Documentation change would be worthwhile here... but I'll wait for your
changes before doing anything there,

Best Regards, Simon Riggs


Mon, 4 Oct 2004 10:17:29 +0100
"Simon Riggs" <simon@2ndquadrant.com>
Re: shared memory release following failed lock acquirement. 