From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Merlin Moncure" <merlin(dot)moncure(at)rcsonline(dot)com> |
Cc: | "PostgreSQL-development" <pgsql-hackers(at)postgresql(dot)org>, "Alvaro Herrera" <alvherre(at)dcc(dot)uchile(dot)cl> |
Subject: | Re: pg_locks needs a facelift |
Date: | 2005-05-03 02:43:01 |
Message-ID: | 4812.1115088181@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Merlin Moncure" <merlin(dot)moncure(at)rcsonline(dot)com> writes:
> Yep. Actually, the biggest part of this was figuring out what to do
> about the pg_locks view. Since that's basically decided, all that
> remains is to decide what if anything to do about the
> max_locks_per_transaction GUC variable. User locks at the very least
> are extra-transactional so this could perhaps be renamed.
I'm not in favor of renaming the variable unless a really significantly
more descriptive name is proposed. I can't think of any short names
that are markedly better than max_locks_per_transaction. To me the
main shortcoming of that name has nothing to do with user locks: it's
that it suggests that we enforce a hard limit on each transaction
individually, when in fact we do no such thing (the limit is on the
total number of locks in existence, not how many are owned by whom).
> FWIW, I'm a huge fan of the current behavior which is to drop
> transactions when running out of lock-space.
I can't quite tell if that was supposed to have a smiley or not ...
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Neil Conway | 2005-05-03 03:03:43 | Re: [pgsql-advocacy] Increased company involvement |
Previous Message | Oliver Jowett | 2005-05-03 01:49:56 | Implement support for TCP_KEEPCNT, TCP_KEEPIDLE, TCP_KEEPINTVL (was Re: [HACKERS] Feature freeze date for 8.1) |