From: | "Merlin Moncure" <merlin(dot)moncure(at)rcsonline(dot)com> |
---|---|
To: | "Simon Riggs" <simon(at)2ndquadrant(dot)com> |
Cc: | <pgsql-hackers(at)postgresql(dot)org>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Subject: | Re: shared memory release following failed lock acquirement. |
Date: | 2004-09-30 12:09:30 |
Message-ID: | 6EE64EF3AB31D5448D0007DD34EEB3412A74DB@Herge.rcsinc.local |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> 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
From | Date | Subject | |
---|---|---|---|
Next Message | Merlin Moncure | 2004-09-30 13:45:51 | spurious function execution in prepared statements. |
Previous Message | John DeSoi | 2004-09-30 12:00:45 | looking for pgEdit beta testers |