> > well, the old ones are GPL. I've made a few attempts to contact the
> > original author...he's MIA. Since 95% of the implementation is in
the
> > backend, it seems odd to have a GPL interface.
>
> I agree. Wasn't it you that was proposing to rewrite the module from
> scratch to eliminate the GPL restriction?
>
> regards, tom lane

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. This could
possibly hinge on how Alvaro's 'spill to disk' scenario plays out.

FWIW, I'm a huge fan of the current behavior which is to drop
transactions when running out of lock-space. In any event, I'll rewrite
the interface and the documentation for user-locking with minimal
changes except to expose more of the locktag structure and remove
references to the deprecated and conceptually confusing oid.

Merlin

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

On Mon, May 02, 2005 at 04:34:50PM -0400, Merlin Moncure wrote:

> 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. This could
> possibly hinge on how Alvaro's 'spill to disk' scenario plays out.

Oh, I don't plan to work on locking issues anymore for now. Basically I
wanted spill to disk only to serve the tuple locking, but since we solve
that in a different way, I pretty much abandoned that idea.

--
Alvaro Herrera (<alvherre[@]dcc.uchile.cl>)
"Por suerte hoy explotó el califont porque si no me habría muerto
de aburrido" (Papelucho)

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

"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

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster