Re: pg_locks needs a facelift - Mailing list pgsql-hackers

From Tom Lane
Subject Re: pg_locks needs a facelift
Date
Msg-id 4812.1115088181@sss.pgh.pa.us
Whole thread Raw
In response to Re: pg_locks needs a facelift  ("Merlin Moncure" <merlin.moncure@rcsonline.com>)
List pgsql-hackers
"Merlin Moncure" <merlin.moncure@rcsonline.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


pgsql-hackers by date:

Previous
From: Neil Conway
Date:
Subject: Re: SPI bug.
Next
From: Neil Conway
Date:
Subject: Re: [pgsql-advocacy] Increased company involvement