Re: pg_locks needs a facelift

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

In response to

Browse pgsql-hackers by date

  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)