Thread: User locks code

User locks code

From
"Mikheev, Vadim"
Date:
1. Just noted this in contrib/userlock/README.user_locks:

> User locks, by Massimo Dal Zotto <dz@cs.unitn.it>
> Copyright (C) 1999, Massimo Dal Zotto <dz@cs.unitn.it>
> 
> This software is distributed under the GNU General Public License
> either version 2, or (at your option) any later version.

Well, anyone can put code into contrib with whatever license
he/she want but "user locks" package includes interface
functions in contrib *and* changes in our lock manager, ie
changes in backend code. I wonder if backend' part of package
is covered by the same license above? And is it good if yes?

2. Not good implementation, imho.

It's too complex (separate lock method table, etc). Much cleaner
would be implement this feature the same way as transactions
wait other transaction commit/abort: by locking objects in
pseudo table. We could get rid of offnum and lockmethod from
LOCKTAG and add

struct
{Oid    RelId;Oid    ObjId;
} userObjId;

to objId union of LOCKTAG.

This way user could lock whatever object he/she want in specified
table and note that we would be able to use table access rights to
control if user allowed to lock objects in table - missed in 1.

One could object that 1. is good because user locks never wait.
I argue that "never waiting" for lock is same bad as "always waiting".
Someday we'll have time-wait etc features for general lock method
and everybody will be happy -:)

Comments?

Vadim
P.S. I could add 2. very fast, no matter if we'll keep 1. or not.


RE: User locks code

From
"Vadim Mikheev"
Date:
Well, ability to lock only unlocked rows in select for update is useful,
of course. But uniq features of user'locks are:

1. They don't interfere with normal locks hold by session/transaction.
2. Share lock is available.
3. User can lock *and unlock objects* inside transaction, which is not   (and will not be) available with locks held by
transactions.

They are interesting too and proposed implementation will not impact lock
manager (just additional 4 bytes in LOCKTAG => same size of LOCKTAG
on machines with 8 bytes alignment).

> An interesting method would be to allow users to simply avoid locked
> rows:
>
> SELECT * FROM queue FOR UPDATE LIMIT 1 UNLOCKED;
>
> Unlocked, return immediately, whatever could be used as a keyword to
> avoid rows that are locked (skipping over them).
>
> For update locks the row of course.  Currently for the above type of
> thing I issue an ORDER BY random() which avoids common rows enough,
> the queue agent dies if queries start taking too long (showing it's
> waiting for other things) and tosses up new copies if it goes a while
> without waiting at all (showing increased load).
>
> --
> Rod Taylor
>
> This message represents the official view of the voices in my head
>
> ----- Original Message -----
> From: "Mikheev, Vadim" <vmikheev@SECTORBASE.COM>
> To: <pgsql-hackers@postgresql.org>
> Sent: Friday, August 17, 2001 2:48 PM
> Subject: [HACKERS] User locks code
>
>
> > 1. Just noted this in contrib/userlock/README.user_locks:
> >
> > > User locks, by Massimo Dal Zotto <dz@cs.unitn.it>
> > > Copyright (C) 1999, Massimo Dal Zotto <dz@cs.unitn.it>
> > >
> > > This software is distributed under the GNU General Public License
> > > either version 2, or (at your option) any later version.
> >
> > Well, anyone can put code into contrib with whatever license
> > he/she want but "user locks" package includes interface
> > functions in contrib *and* changes in our lock manager, ie
> > changes in backend code. I wonder if backend' part of package
> > is covered by the same license above? And is it good if yes?
> >
> > 2. Not good implementation, imho.
> >
> > It's too complex (separate lock method table, etc). Much cleaner
> > would be implement this feature the same way as transactions
> > wait other transaction commit/abort: by locking objects in
> > pseudo table. We could get rid of offnum and lockmethod from
> > LOCKTAG and add
> >
> > struct
> >

> > Oid RelId;
> > Oid ObjId;
> > } userObjId;
> >
> > to objId union of LOCKTAG.
> >
> > This way user could lock whatever object he/she want in specified
> > table and note that we would be able to use table access rights to
> > control if user allowed to lock objects in table - missed in 1.
> >
> > One could object that 1. is good because user locks never wait.
> > I argue that "never waiting" for lock is same bad as "always
> waiting".
> > Someday we'll have time-wait etc features for general lock method
> > and everybody will be happy -:)
> >
> > Comments?
> >
> > Vadim
> > P.S. I could add 2. very fast, no matter if we'll keep 1. or not.
> >
> > ---------------------------(end of
> broadcast)---------------------------
> > TIP 3: if posting/reading through Usenet, please send an appropriate
> > subscribe-nomail command to majordomo@postgresql.org so that your
> > message can get through to the mailing list cleanly
> >
>




Re: User locks code

From
"Rod Taylor"
Date:
An interesting method would be to allow users to simply avoid locked
rows:

SELECT * FROM queue FOR UPDATE LIMIT 1 UNLOCKED;

Unlocked, return immediately, whatever could be used as a keyword to
avoid rows that are locked (skipping over them).

For update locks the row of course.  Currently for the above type of
thing I issue an ORDER BY random() which avoids common rows enough,
the queue agent dies if queries start taking too long (showing it's
waiting for other things) and tosses up new copies if it goes a while
without waiting at all (showing increased load).

--
Rod Taylor

This message represents the official view of the voices in my head

----- Original Message -----
From: "Mikheev, Vadim" <vmikheev@SECTORBASE.COM>
To: <pgsql-hackers@postgresql.org>
Sent: Friday, August 17, 2001 2:48 PM
Subject: [HACKERS] User locks code


> 1. Just noted this in contrib/userlock/README.user_locks:
>
> > User locks, by Massimo Dal Zotto <dz@cs.unitn.it>
> > Copyright (C) 1999, Massimo Dal Zotto <dz@cs.unitn.it>
> >
> > This software is distributed under the GNU General Public License
> > either version 2, or (at your option) any later version.
>
> Well, anyone can put code into contrib with whatever license
> he/she want but "user locks" package includes interface
> functions in contrib *and* changes in our lock manager, ie
> changes in backend code. I wonder if backend' part of package
> is covered by the same license above? And is it good if yes?
>
> 2. Not good implementation, imho.
>
> It's too complex (separate lock method table, etc). Much cleaner
> would be implement this feature the same way as transactions
> wait other transaction commit/abort: by locking objects in
> pseudo table. We could get rid of offnum and lockmethod from
> LOCKTAG and add
>
> struct
> {
> Oid RelId;
> Oid ObjId;
> } userObjId;
>
> to objId union of LOCKTAG.
>
> This way user could lock whatever object he/she want in specified
> table and note that we would be able to use table access rights to
> control if user allowed to lock objects in table - missed in 1.
>
> One could object that 1. is good because user locks never wait.
> I argue that "never waiting" for lock is same bad as "always
waiting".
> Someday we'll have time-wait etc features for general lock method
> and everybody will be happy -:)
>
> Comments?
>
> Vadim
> P.S. I could add 2. very fast, no matter if we'll keep 1. or not.
>
> ---------------------------(end of
broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo@postgresql.org so that your
> message can get through to the mailing list cleanly
>



RE: User locks code

From
Lincoln Yeoh
Date:
At 11:20 AM 8/19/01 -0700, Vadim Mikheev wrote:
>Well, ability to lock only unlocked rows in select for update is useful,
>of course. But uniq features of user'locks are:
>
>1. They don't interfere with normal locks hold by session/transaction.
>2. Share lock is available.
>3. User can lock *and unlock objects* inside transaction, which is not
>    (and will not be) available with locks held by transactions.

Would your suggested implementation allow locking on an arbitrary string?

If it does then one of the things I'd use it for is to insert unique data
without having to lock the table or rollback on failed insert (unique index
still kept as a guarantee).

Cheerio,
Link.






RE: User locks code

From
"Mikheev, Vadim"
Date:
> Would your suggested implementation allow locking on an
> arbitrary string?

Well, placing string in LOCKTAG is not good so we could
create auxilary hash table in shmem to keep such strings
and use string' address as part of LOCKTAG. New function
(LockRelationKey?) in lmgr.c would first find/place
key in that table, than construct LOCKTAG and call
LockAcquire.
Possible syntax:

LOCK TABLE relation IN {SHARE | EXCLUSIVE} MODEON KEY user-string [FOR TRANSACTION | FOR SESSION];

UNLOCK (RELEASE?) TABLE relation {SHARE | EXCLUSIVE} LOCKON KEY user-string;

(or just some built-in functions).

> If it does then one of the things I'd use it for is to insert
> unique data without having to lock the table or rollback on
> failed insert (unique index still kept as a guarantee).

(Classic example how could be used SAVEPOINTs -:))

So, in your application you would first lock a key in excl mode
(for duration of transaction), than try to select and insert unless
found? (Note that this will not work with serializable isolevel.)

Comments?

Vadim


RE: User locks code

From
Lincoln Yeoh
Date:
At 09:39 AM 20-08-2001 -0700, Mikheev, Vadim wrote:
>> If it does then one of the things I'd use it for is to insert
>> unique data without having to lock the table or rollback on
>> failed insert (unique index still kept as a guarantee).
>
>(Classic example how could be used SAVEPOINTs -:))

I guess so. But this could be faster.

>So, in your application you would first lock a key in excl mode
>(for duration of transaction), than try to select and insert unless
>found? (Note that this will not work with serializable isolevel.)

yep:
lock "tablename.colname.val=1"
select count(*) from tablename where colname=1
If no rows, insert, else update.
(dunno if the locks would scale to a scenario with hundreds of concurrent
inserts - how many user locks max?).

Why wouldn't it work with serializable isolevel?

Anyway, I believe that isolevel doesn't really serialise things in this
case (inserting a unique row) so it wouldn't matter to me.

Regards,
Link.



Postgresql log analyzer

From
Gilles DAROLD
Date:
Hi all,

I'm currently trying to develop a log analyzer for PostgreSQL logs and at
the first
stage I'm finding a little problem with the postgresql.conf option
log_timestamp.

The problem is that if this option is set to false we have no idea of when
the backend
is started:

DEBUG:  database system was shut down at 2001-08-20 21:51:54 CEST
DEBUG:  CheckPoint record at (0, 126088776)
DEBUG:  Redo record at (0, 126088776); Undo record at (0, 0); Shutdown TRUE
DEBUG:  NextTransactionId: 489793; NextOid: 77577
DEBUG:  database system is in production state

Is it possible to have it into the last line as we have the information of
the database
shutdown timestamp in the first line ?

Also, an other question is why using timestamp into the other log instead of
the value
of  time  in  seconds  since  the  Epoch like the time() function do ?

I don't know if it is speedest or not but if timestamp is system local
dependant
I think it should be very difficult to me to have a portable log analyzer...

Regards,

Gilles Darold



RE: User locks code

From
"Mikheev, Vadim"
Date:
> yep:
> lock "tablename.colname.val=1"
> select count(*) from tablename where colname=1
> If no rows, insert, else update.
> (dunno if the locks would scale to a scenario with hundreds
> of concurrent inserts - how many user locks max?).

I don't see problem here - just a few bytes in shmem for
key. Auxiliary table would keep refcounters for keys.

> Why wouldn't it work with serializable isolevel?

Because of selects see old database snapshot and so you
wouldn't see key inserted+committed by concurrent tx.

Vadim


RE: User locks code

From
"Mikheev, Vadim"
Date:
> Regarding the licencing of the code, I always release my code
> under GPL, which is the licence I prefer, but my code in the
> backend is obviously released under the original postgres
> licence. Since the module is loaded dynamically and not linked
> into the backend I don't see a problem here.

The problem is how to use user-locks in commercial projects.
Some loadable interface functions are required to use in-backend
user lock code, but interface is so simple - if one would write
new functions they would look the same as yours covered by GPL.

> If the licence becomes a problem I can easily change it, but
> I prefer the GPL if possible.

Actually I don't see why to cover your contrib module by GPL.
Not so much IP (intellectual property) there. Real new things
which make new feature possible are in lock manager.

Vadim


Re: Postgresql log analyzer

From
Peter Eisentraut
Date:
Gilles DAROLD writes:

> Is it possible to have it into the last line as we have the information of
> the database
> shutdown timestamp in the first line ?

We not just turn time stamping on?

> Also, an other question is why using timestamp into the other log instead of
> the value
> of  time  in  seconds  since  the  Epoch like the time() function do ?

Because humans generally reckon time the former way.

> I don't know if it is speedest or not but if timestamp is system local
> dependant
> I think it should be very difficult to me to have a portable log analyzer...

In the current system, the timestamp is not locale dependent, but that
doesn't mean that it could be in the future.  (I wouldn't find it
particularly useful, because the current format is internationally
readable.)

What *is* locale dependent are the messages, though.  Not sure how you
plan to deal with that.

-- 
Peter Eisentraut   peter_e@gmx.net   http://funkturm.homeip.net/~peter



Re: RE: User locks code

From
Tom Lane
Date:
"Mikheev, Vadim" <vmikheev@SECTORBASE.COM> writes:
>> (dunno if the locks would scale to a scenario with hundreds
>> of concurrent inserts - how many user locks max?).

> I don't see problem here - just a few bytes in shmem for
> key. Auxiliary table would keep refcounters for keys.

I think that running out of shmem *would* be a problem for such a
facility.  We have a hard enough time now sizing the lock table for
system locks, even though they use fixed-size keys and the system as
a whole is designed to ensure that not too many locks will be held
simultaneously.  (For example, SELECT FOR UPDATE doesn't try to use
per-tuple locks.)  Earlier in this thread, someone proposed using
user locks as a substitute for SELECT FOR UPDATE.  I can guarantee
you that that someone will run out of shared memory before long,
if the userlock table resides in shared memory.
        regards, tom lane


Re: Postgresql log analyzer

From
Gilles DAROLD
Date:
Hi all,

Here is a first draft generated by a log analyzer for postgres I've wrote today:

    http://www.samse.fr/GPL/log_report/

In all this html report there is what I'm able to extract minus the statistics.

I need to know what people want to see reported to have a powerfull log analyzer,

I can spend this week do do that...

Peter, sorry for my poor english that what I mean is that if you don't activated
the
log_timestamp option we have no idea when the postmaster have been started
(or at least doing a ls -la on /tmp/.s.PGSQL.5432). Other things was just
question
and you answer them, thanks.

Regards



RE: RE: User locks code

From
"Mikheev, Vadim"
Date:
> > I don't see problem here - just a few bytes in shmem for
> > key. Auxiliary table would keep refcounters for keys.
> 
> I think that running out of shmem *would* be a problem for such a
> facility.  We have a hard enough time now sizing the lock table for

Auxiliary table would have fixed size and so no new keys would be
added if no space. I don't see problem with default 8Kb aux table,
do you?

> system locks, even though they use fixed-size keys and the system as
> a whole is designed to ensure that not too many locks will be held
> simultaneously.  (For example, SELECT FOR UPDATE doesn't try to use
> per-tuple locks.)  Earlier in this thread, someone proposed using
> user locks as a substitute for SELECT FOR UPDATE.  I can guarantee
> you that that someone will run out of shared memory before long,
> if the userlock table resides in shared memory.

How is proposed "key locking" is different from user locks we
have right now? Anyone can try to acquire many-many user locks.

Vadim


Re: Postgresql log analyzer

From
Andrew McMillan
Date:
Gilles DAROLD wrote:
>
> Hi all,
>
> Here is a first draft generated by a log analyzer for postgres I've wrote today:
>
>     http://www.samse.fr/GPL/log_report/
>
> In all this html report there is what I'm able to extract minus the statistics.
>
> I need to know what people want to see reported to have a powerfull log analyzer,

I like what you have there so far.

For my own use I would like to see the ability to turn some of these off,
and also perhaps a summary page that you would click through to the more
detailed reports.

The 'query' page is kind of complicated too.  Would it be possible to put
that into a table layout as well?
+-------------------------------+
|select...                      |
+----+----+----+--------+-------+
|stat|stat|stat|stat ...|       |
+----+----+----+--------+-------+

sort of layout.

It would be nice to see an EXPLAIN on the query page, but you would want
this to be an option, I guess.  I imagine you could do this by getting the
EXPLAIN at log analysis time if it isn't in the logs.

Cheers,
                    Andrew.
--
_____________________________________________________________________
        Andrew McMillan, e-mail: Andrew @ catalyst . net . nz
Catalyst IT Ltd, PO Box 10-225, Level 22, 105 The Terrace, Wellington
Me: +64(21)635-694,  Fax:+64(4)499-5596, Office: +64(4)499-2267xtn709

Re: [GENERAL] Postgresql log analyzer

From
Gilles DAROLD
Date:
Hi all,

I have updated the drafts for pg log analyzer especially for EXPLAIN  output.
What do you want to see as statistics result. Currently I only output the following:

- scan type
- startup cost
- total cost
- number of rows returned
- and the width

There's certainly other usefull information but I don't know. Please let me know !

Note:

This is a simple draft to show what can be done, as a general purpose it will include:

- A configuration file (to choose what should be reported, paths, etc...)
   or/and command line args
- An index page with resume of all reports
- Incremental scan working on full or rotate log

For other good requests it's done...

Let me know any other requests otherwise I will publish the first release at least on
monday
if not tomorow !

    http://www.samse.fr/GPL/log_report/

Regards,

Gilles Darold

Andrew McMillan wrote:

> Gilles DAROLD wrote:
> >
> > Hi all,
> >
> > Here is a first draft generated by a log analyzer for postgres I've wrote today:
> >
> >     http://www.samse.fr/GPL/log_report/
> >
> > In all this html report there is what I'm able to extract minus the statistics.
> >
> > I need to know what people want to see reported to have a powerfull log analyzer,
>
> I like what you have there so far.
>
> For my own use I would like to see the ability to turn some of these off,
> and also perhaps a summary page that you would click through to the more
> detailed reports.
>
> The 'query' page is kind of complicated too.  Would it be possible to put
> that into a table layout as well?
> +-------------------------------+
> |select...                      |
> +----+----+----+--------+-------+
> |stat|stat|stat|stat ...|       |
> +----+----+----+--------+-------+
>
> sort of layout.
>
> It would be nice to see an EXPLAIN on the query page, but you would want
> this to be an option, I guess.  I imagine you could do this by getting the
> EXPLAIN at log analysis time if it isn't in the logs.
>
> Cheers,
>                                         Andrew.
> --
> _____________________________________________________________________
>         Andrew McMillan, e-mail: Andrew @ catalyst . net . nz
> Catalyst IT Ltd, PO Box 10-225, Level 22, 105 The Terrace, Wellington
> Me: +64(21)635-694,  Fax:+64(4)499-5596, Office: +64(4)499-2267xtn709
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/users-lounge/docs/faq.html




Re: User locks code

From
Massimo Dal Zotto
Date:
> Well, ability to lock only unlocked rows in select for update is useful,
> of course. But uniq features of user'locks are:
> 
> 1. They don't interfere with normal locks hold by session/transaction.
> 2. Share lock is available.
> 3. User can lock *and unlock objects* inside transaction, which is not
>     (and will not be) available with locks held by transactions.
> 
> They are interesting too and proposed implementation will not impact lock
> manager (just additional 4 bytes in LOCKTAG => same size of LOCKTAG
> on machines with 8 bytes alignment).
> 
> > An interesting method would be to allow users to simply avoid locked
> > rows:
> >
> > SELECT * FROM queue FOR UPDATE LIMIT 1 UNLOCKED;
> >
> > Unlocked, return immediately, whatever could be used as a keyword to
> > avoid rows that are locked (skipping over them).
> >
> > For update locks the row of course.  Currently for the above type of
> > thing I issue an ORDER BY random() which avoids common rows enough,
> > the queue agent dies if queries start taking too long (showing it's
> > waiting for other things) and tosses up new copies if it goes a while
> > without waiting at all (showing increased load).
> >
> > --
> > Rod Taylor
> >
> > This message represents the official view of the voices in my head
> >
> > ----- Original Message -----
> > From: "Mikheev, Vadim" <vmikheev@SECTORBASE.COM>
> > To: <pgsql-hackers@postgresql.org>
> > Sent: Friday, August 17, 2001 2:48 PM
> > Subject: [HACKERS] User locks code
> >
> >
> > > 1. Just noted this in contrib/userlock/README.user_locks:
> > >
> > > > User locks, by Massimo Dal Zotto <dz@cs.unitn.it>
> > > > Copyright (C) 1999, Massimo Dal Zotto <dz@cs.unitn.it>
> > > >
> > > > This software is distributed under the GNU General Public License
> > > > either version 2, or (at your option) any later version.
> > >
> > > Well, anyone can put code into contrib with whatever license
> > > he/she want but "user locks" package includes interface
> > > functions in contrib *and* changes in our lock manager, ie
> > > changes in backend code. I wonder if backend' part of package
> > > is covered by the same license above? And is it good if yes?
> > >
> > > 2. Not good implementation, imho.
> > >
> > > It's too complex (separate lock method table, etc). Much cleaner
> > > would be implement this feature the same way as transactions
> > > wait other transaction commit/abort: by locking objects in
> > > pseudo table. We could get rid of offnum and lockmethod from
> > > LOCKTAG and add
> > >
> > > struct
> > >
> 
> > > Oid RelId;
> > > Oid ObjId;
> > > } userObjId;
> > >
> > > to objId union of LOCKTAG.
> > >
> > > This way user could lock whatever object he/she want in specified
> > > table and note that we would be able to use table access rights to
> > > control if user allowed to lock objects in table - missed in 1.
> > >
> > > One could object that 1. is good because user locks never wait.
> > > I argue that "never waiting" for lock is same bad as "always
> > waiting".
> > > Someday we'll have time-wait etc features for general lock method
> > > and everybody will be happy -:)
> > >
> > > Comments?
> > >
> > > Vadim
> > > P.S. I could add 2. very fast, no matter if we'll keep 1. or not.
> > >

4. Most important: user locks are retained across transaction, which is  not possible with ordinary locks.

5. User locks semantic is defined entirely by the application and is not  related to rows in the database.

I wrote the user locks code because I needed a method to mark items as
`busy' for very long time to avoid more users modifying the same object
and overwriting each one's changes. This requires two features:
   1.    they must survive transaction boundary. The typical use of userlocks is:
    transaction 1:    select object,user_lock(object);
    ... work on object for long time
    transaction 2: update object,user_unlock(object);
   2.    they must not block if the object is already locked, so that theprogram doesn't freeze and the user simply
knowsit can't use thatobject.
 

When I wrote the code the only way to do this was to add a separate lock
table and use the same machinery of ordinary locks. I agree that the code
is complex and should probably be rewritten.

If you think there is a better way to implement this feature go ahead,
better code is always welcome.

The only problem I have found with user locks is that if a backend crashes
without releasing a lock there is no way to relase it except restarting
the whole postgres (I don't remember exactly why, I forgot the details).

Regarding the licencing of the code, I always release my code under GPL,
which is the licence I prefer, but my code in the backend is obviously
released under the original postgres licence. Since the module is loaded
dynamically and not linked into the backend I don't see a problem here.
If the licence becomes a problem I can easily change it, but I prefer the
GPL if possible.

-- 
Massimo Dal Zotto

+----------------------------------------------------------------------+
|  Massimo Dal Zotto               email: dz@cs.unitn.it               |
|  Via Marconi, 141                phone: ++39-0461534251              |
|  38057 Pergine Valsugana (TN)      www: http://www.cs.unitn.it/~dz/  |
|  Italy                             pgp: see my www home page         |
+----------------------------------------------------------------------+


RE: User locks code

From
"Mikheev, Vadim"
Date:
> > If the licence becomes a problem I can easily change it,
> > but I prefer the GPL if possible.
> 
> We just wanted to make sure the backend changes were not
> under the GPL.

No, Bruce - backend part of code is useless without interface
functions and I wonder doesn't GPL-ed interface implementation
prevent using of user-locks in *commercial* applications.
For example, one could use user-locks for processing incoming
orders by multiple operators:
select * from orders where user_lock(orders.oid) = 1 LIMIT 1
- so each operator would lock one order for processing and
operators wouldn't block each other. So, could such
application be commercial with current licence of
user_lock()? (Sorry, I'm not licence guru.)

DISCLAIMER (to avoid ungrounded rumors -:))
I have no plans to use user-locks in applications
of *any* kind (free/commercial). It's just matter of
principle - anything in/from backend code maybe used
for any purposes, - that's nature of our licence.

DISCLAIMER II (to avoid ungrounded rumors in future -:))
I would be interested in using proposed "key-locking"
in some particular commercial application but this
feature is not "must have" for that application -
for my purposes it's enough:

----------------------------------------------------------
LOCKTAG tag;
tag.relId = XactLockTableId;
tag.dbId = _tableId_;
// tag.dbId = InvalidOid is used in XactLockTableInsert
// and no way to use valid OID for XactLock purposes,
// so no problem
tag.objId.xid = _user_key_;
----------------------------------------------------------

- but I like standard solutions more -:)
(BTW, key-locking was requested by others a long ago.)

Vadim


Re: User locks code

From
Bruce Momjian
Date:
> > > If the licence becomes a problem I can easily change it,
> > > but I prefer the GPL if possible.
> > 
> > We just wanted to make sure the backend changes were not
> > under the GPL.
> 
> No, Bruce - backend part of code is useless without interface
> functions and I wonder doesn't GPL-ed interface implementation
> prevent using of user-locks in *commercial* applications.
> For example, one could use user-locks for processing incoming
> orders by multiple operators:
> select * from orders where user_lock(orders.oid) = 1 LIMIT 1
> - so each operator would lock one order for processing and
> operators wouldn't block each other. So, could such
> application be commercial with current licence of
> user_lock()? (Sorry, I'm not licence guru.)

I assume any code that uses contrib/userlock has to be GPL'ed, meaning
it can be used for commercial purposes but can't be sold as binary-only,
and actually can't be sold for much because you have to make the code
available for near-zero cost.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026
 


RE: User locks code

From
"Mikheev, Vadim"
Date:
> > For example, one could use user-locks for processing incoming
> > orders by multiple operators:
> > select * from orders where user_lock(orders.oid) = 1 LIMIT 1
> > - so each operator would lock one order for processing and
> > operators wouldn't block each other. So, could such
> > application be commercial with current licence of
> > user_lock()? (Sorry, I'm not licence guru.)
> 
> I assume any code that uses contrib/userlock has to be GPL'ed,
> meaning it can be used for commercial purposes but can't be sold
> as binary-only, and actually can't be sold for much because you
> have to make the code available for near-zero cost.

I'm talking not about solding contrib/userlock separately, but
about ability to sold applications which use contrib/userlock.
Sorry, if it was not clear.

Vadim


Re: User locks code

From
Bruce Momjian
Date:
> > > For example, one could use user-locks for processing incoming
> > > orders by multiple operators:
> > > select * from orders where user_lock(orders.oid) = 1 LIMIT 1
> > > - so each operator would lock one order for processing and
> > > operators wouldn't block each other. So, could such
> > > application be commercial with current licence of
> > > user_lock()? (Sorry, I'm not licence guru.)
> > 
> > I assume any code that uses contrib/userlock has to be GPL'ed,
> > meaning it can be used for commercial purposes but can't be sold
> > as binary-only, and actually can't be sold for much because you
> > have to make the code available for near-zero cost.
> 
> I'm talking not about solding contrib/userlock separately, but
> about ability to sold applications which use contrib/userlock.
> Sorry, if it was not clear.

No, you were clear.  My assumption is that once you link that code into
the backend, the entire backend is GPL'ed and any other application code
you link into it is also (stored procedures, triggers, etc.)  I don't
think your client application will be GPL'ed, assuming you didn't link
in libreadline.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026
 


RE: User locks code

From
"Mikheev, Vadim"
Date:
> > > I assume any code that uses contrib/userlock has to be GPL'ed,
> > > meaning it can be used for commercial purposes but can't be sold
> > > as binary-only, and actually can't be sold for much because you
> > > have to make the code available for near-zero cost.
> > 
> > I'm talking not about solding contrib/userlock separately, but
> > about ability to sold applications which use contrib/userlock.
> > Sorry, if it was not clear.
> 
> No, you were clear.

So I missed your "near-zero cost" sentence.

> My assumption is that once you link that code into
> the backend, the entire backend is GPL'ed and any other
> application code you link into it is also (stored procedures,
> triggers, etc.) I don't think your client application will
> be GPL'ed, assuming you didn't link in libreadline.

Application would explicitly call user_lock() functions in
queries, so issue is still not clear for me. And once again -
compare complexities of contrib/userlock and backend' userlock
code: what's reason to cover contrib/userlock by GPL?

Vadim


Re: User locks code

From
Bruce Momjian
Date:
> > No, you were clear.
> 
> So I missed your "near-zero cost" sentence.

OK.

> > My assumption is that once you link that code into
> > the backend, the entire backend is GPL'ed and any other
> > application code you link into it is also (stored procedures,
> > triggers, etc.) I don't think your client application will
> > be GPL'ed, assuming you didn't link in libreadline.
> 
> Application would explicitly call user_lock() functions in
> queries, so issue is still not clear for me. And once again -

Well, yes, it calls user_lock(), but the communication is not OS-linked,
it is linked over a network socket, so I don't think the GPL spreads
over a socket.  Just as telnet'ing somewhere an typing 'bash' doesn't
make your telnet GPL'ed, so I think the client code is safe.  To the
client, the backend is just returning information.  You don't really
link to the query results.

> compare complexities of contrib/userlock and backend' userlock
> code: what's reason to cover contrib/userlock by GPL?

Only because Massimo prefers it.  I can think of no other reason.  It
clearly GPL-stamps any backend that links it in.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026
 


RE: User locks code

From
"Mikheev, Vadim"
Date:
> > Application would explicitly call user_lock() functions in
> > queries, so issue is still not clear for me. And once again -
> 
> Well, yes, it calls user_lock(), but the communication is not
> OS-linked, it is linked over a network socket, so I don't think
> the GPL spreads over a socket. Just as telnet'ing somewhere an
> typing 'bash' doesn't make your telnet GPL'ed, so I think the
> client code is safe. To the client, the backend is just
> returning information. You don't really link to the query
> results.

Ah, ok.

> > compare complexities of contrib/userlock and backend' userlock
> > code: what's reason to cover contrib/userlock by GPL?
> 
> Only because Massimo prefers it. I can think of no other reason.
> It clearly GPL-stamps any backend that links it in.

Ok, let's do one step back - you wrote:

> My assumption is that once you link that code into the backend,
> the entire backend is GPL'ed and any other application code
> you link into it is also (stored procedures, triggers, etc.)

So, one would have to open-source and GPL all procedures/triggers
used by application just because of application uses user_lock()
in queries?! Is it good?

Vadim


Re: User locks code

From
Bruce Momjian
Date:
> > Well, yes, it calls user_lock(), but the communication is not
> > OS-linked, it is linked over a network socket, so I don't think
> > the GPL spreads over a socket. Just as telnet'ing somewhere an
> > typing 'bash' doesn't make your telnet GPL'ed, so I think the
> > client code is safe. To the client, the backend is just
> > returning information. You don't really link to the query
> > results.
> 
> Ah, ok.

Yes, kind of tricky.  I am no expert in this but I have had the usual
discussions.

> > > compare complexities of contrib/userlock and backend' userlock
> > > code: what's reason to cover contrib/userlock by GPL?
> > 
> > Only because Massimo prefers it. I can think of no other reason.
> > It clearly GPL-stamps any backend that links it in.
> 
> Ok, let's do one step back - you wrote:
> 
> > My assumption is that once you link that code into the backend,
> > the entire backend is GPL'ed and any other application code
> > you link into it is also (stored procedures, triggers, etc.)
> 
> So, one would have to open-source and GPL all procedures/triggers
> used by application just because of application uses user_lock()
> in queries?! Is it good?

Yep.  Is it good?  Well, if you like the GPL, I guess so.  If you don't,
then it isn't good.  

Of course, if you want to try and make money selling your program, it
isn't good whether you like the GPL or not.  :-)

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026
 


Re: User locks code

From
Tom Lane
Date:
I definitely agree with Vadim here: it's fairly silly that the
contrib userlock code is GPL'd, when it consists only of a few dozen
lines of wrapper for the real functionality that's in the main backend.
The only thing this licensing setup can accomplish is to discourage
people from using the userlock code; what's the value of that?

Besides, anyone who actually wanted to use the userlock code would need
only to write their own wrapper functions to get around the GPL license.
        regards, tom lane


Re: User locks code

From
Bruce Momjian
Date:
> I definitely agree with Vadim here: it's fairly silly that the
> contrib userlock code is GPL'd, when it consists only of a few dozen
> lines of wrapper for the real functionality that's in the main backend.
> The only thing this licensing setup can accomplish is to discourage
> people from using the userlock code; what's the value of that?
> 
> Besides, anyone who actually wanted to use the userlock code would need
> only to write their own wrapper functions to get around the GPL license.

Hey, I agree with Vadim too.  The GPL license is just a roadblock, but I
can't tell Massimo what to do with his code if it is not in the backend
proper.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026
 


Re: User locks code

From
Hannu Krosing
Date:
Tom Lane wrote:
> 
> I definitely agree with Vadim here: it's fairly silly that the
> contrib userlock code is GPL'd, when it consists only of a few dozen
> lines of wrapper for the real functionality that's in the main backend.

As it seems a generally useful feature, it could at least be LGPL'd so 
that linking to it won't force the whole backend under GPL.

> The only thing this licensing setup can accomplish is to discourage
> people from using the userlock code; what's the value of that?

Maybe it makes Massimo feel good ? It seems a worhty reason to me, as 
he has contributed a lot of useful stuff over the time.

I really think that mixing licences inside one program is bad, if not
for 
any other reason then for confusing people and making them have
discussions 
like this.

> Besides, anyone who actually wanted to use the userlock code would need
> only to write their own wrapper functions to get around the GPL license.

This is a part of copyright law that eludes me - can i write a
replacement
function for something so simple that it can essentially be done in one 
way only (like incrementing a value by one) ?

-----------------
Hannu


Re: User locks code

From
Bruce Momjian
Date:
> Tom Lane wrote:
> > 
> > I definitely agree with Vadim here: it's fairly silly that the
> > contrib userlock code is GPL'd, when it consists only of a few dozen
> > lines of wrapper for the real functionality that's in the main backend.
> 

I was incorrect in something I said to Vadim.  I said stored procedures
would have to be released if linked against a GPL'ed backend.  They have
to be released only if they are in C or another object file linked into
the backend.  PlpgSQL or SQL functions don't have to be released because
their code is "loaded" into the backend as a script, not existing in the
backend binary or required for the backend to run.

> Maybe it makes Massimo feel good ? It seems a worhty reason to me, as 
> he has contributed a lot of useful stuff over the time.

Yes, that is probably it.  The GPL doesn't give anything to users, it
takes some control away from users and gives it to the author of the
code.

> I really think that mixing licences inside one program is bad, if not
> for 
> any other reason then for confusing people and making them have
> discussions 
> like this.

Yes, the weird part is that the BSD license is so lax (don't sue us)
that it is the addition of the GPL that changes the affect of the
license.  If you added a BSD license to a GPL'ed piece of code, the
effect would be near zero.

> > Besides, anyone who actually wanted to use the userlock code would need
> > only to write their own wrapper functions to get around the GPL license.
> 
> This is a part of copyright law that eludes me - can i write a
> replacement
> function for something so simple that it can essentially be done in one 
> way only (like incrementing a value by one) ?

Sure, if you don't cut and paste the code line by line, or retype the
code while staring at the previous version.  That is how Berkeley got
unix-free version of the BSD operating system.  However, the few places
where they lazily copied got them in trouble.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026
 


Re: User locks code

From
Hannu Krosing
Date:
Bruce Momjian wrote:
> 
> >
> > This is a part of copyright law that eludes me - can i write a
> > replacement
> > function for something so simple that it can essentially be done in one
> > way only (like incrementing a value by one) ?
> 
> Sure, if you don't cut and paste the code line by line, or retype the
> code while staring at the previous version.  That is how Berkeley got
> unix-free version of the BSD operating system.  However, the few places
> where they lazily copied got them in trouble.
>

I can imagine that when writing a trivial code for performing a trivial
and 
well-known function it is quite possible to arrive at a result that is 
virtually indistinguishable from the original.

I know that Compaq was forced to do a clean-room re-engineering of PC
BIOS 
(two teams - the dirti one with access to real bios athat does
description 
and testin and the clean team to write the actual code so that they can 
prove they did not "steal" even if the result is byte-by-byte simila)
for 
similar reasons

I guess we dont have enough provably clean developers to do it ;)

BTW, teher seems to be some problem with mailing list - I get very few 
messages from the list that are not CC:d to me too

------------------
Hannu


Re: User locks code

From
teg@redhat.com (Trond Eivind Glomsrød)
Date:
Bruce Momjian <pgman@candle.pha.pa.us> writes:

> > Tom Lane wrote:
> > > 
> > > I definitely agree with Vadim here: it's fairly silly that the
> > > contrib userlock code is GPL'd, when it consists only of a few dozen
> > > lines of wrapper for the real functionality that's in the main backend.
> > 
> 
> I was incorrect in something I said to Vadim.  I said stored procedures
> would have to be released if linked against a GPL'ed backend. 

Only to those you actually distribute this product to. If you're using
it internally, you have no obligations to release it to anyone, to
give one example.

-- 
Trond Eivind Glomsrød
Red Hat, Inc.


[OT] Re: User locks code

From
"Serguei Mokhov"
Date:
----- Original Message ----- 
From: Bruce Momjian <pgman@candle.pha.pa.us>
Sent: Friday, August 24, 2001 10:42 AM


> > I really think that mixing licences inside one program is bad, if not
> > for 
> > any other reason then for confusing people and making them have
> > discussions 
> > like this.
> 
> Yes, the weird part is that the BSD license is so lax (don't sue us)
> that it is the addition of the GPL that changes the affect of the
> license.  If you added a BSD license to a GPL'ed piece of code, the
> effect would be near zero.

Sorry for asking this off-topic question, but I'm not sure I completely
understand this license issue... How GPL, LGPL, and BSD are conflicting
and or overlap, so that it causes such problems? AFAIK with the GPL
one has to ship the source code along with the product every time, but
under BSD it can be shipped without the source (that's why M$ doesn't attack
BSD as it does for GPL), and why the PostgreSQL project originally is being
released under the BSD-like license? Just curious...

Serguei




[OT] Re: User locks code

From
"Serguei Mokhov"
Date:
----- Original Message ----- 
From: Bruce Momjian <pgman@candle.pha.pa.us>
Sent: Friday, August 24, 2001 10:42 AM


> > I really think that mixing licences inside one program is bad, if not
> > for 
> > any other reason then for confusing people and making them have
> > discussions 
> > like this.
> 
> Yes, the weird part is that the BSD license is so lax (don't sue us)
> that it is the addition of the GPL that changes the affect of the
> license.  If you added a BSD license to a GPL'ed piece of code, the
> effect would be near zero.

Sorry for asking this off-topic question, but I'm not sure I completely
understand this license issue... How GPL, LGPL, and BSD are conflicting
and or overlap, so that it causes such problems? AFAIK with the GPL
one has to ship the source code along with the product every time, but
under BSD it can be shipped without the source (that's why M$ doesn't attack
BSD as it does for GPL), and why the PostgreSQL project originally is being
released under the BSD-like license? Just curious...

Serguei




Re: User locks code

From
Bruce Momjian
Date:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> 
> > > Tom Lane wrote:
> > > > 
> > > > I definitely agree with Vadim here: it's fairly silly that the
> > > > contrib userlock code is GPL'd, when it consists only of a few dozen
> > > > lines of wrapper for the real functionality that's in the main backend.
> > > 
> > 
> > I was incorrect in something I said to Vadim.  I said stored procedures
> > would have to be released if linked against a GPL'ed backend. 
> 
> Only to those you actually distribute this product to. If you're using
> it internally, you have no obligations to release it to anyone, to
> give one example.

Yes, I was speaking only of selling the software.  Good point.
--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026
 


RE: User locks code

From
"Mikheev, Vadim"
Date:
> > Besides, anyone who actually wanted to use the userlock
> > code would need only to write their own wrapper functions
> > to get around the GPL license.
> 
> This is a part of copyright law that eludes me - can i write
> a replacement function for something so simple that it can
> essentially be done in one way only (like incrementing a
> value by one) ?

Yes, this is what bothers me in user-lock case.
On the other hand contrib/user-lock' licence
cannot cover usage of LOCKTAG and LockAcquire
(because of this code is from backend) and this is
all what used in user_lock funcs. So, that licence
is unenforceable to everything... except of func names -:)

Vadim


Re: User locks code

From
"Ross J. Reedstrom"
Date:
Uh, guys? The last thing I can find that Massimo says about the license
is this, from Sunday:

On Sun, Aug 19, 2001 at 11:15:54PM +0200, Massimo Dal Zotto wrote:
> 
> Regarding the licencing of the code, I always release my code under GPL,
> which is the licence I prefer, but my code in the backend is obviously
> released under the original postgres licence. Since the module is loaded
> dynamically and not linked into the backend I don't see a problem here.
> If the licence becomes a problem I can easily change it, but I prefer the
> GPL if possible.
> 

So, rather than going over everone's IANAL opinons about mixing
licenses, let's just let Massimo know that it'd just be a lot easier to
PostgreSQL/BSD license the whole thing, if he doesn't mind too much.

Ross

On Fri, Aug 24, 2001 at 10:42:48AM -0400, Bruce Momjian wrote:
<I'm not sure who wrote this, Bruce trimmed the attribution>
> > Maybe it makes Massimo feel good ? It seems a worhty reason to me, as 
> > he has contributed a lot of useful stuff over the time.
> 
> Yes, that is probably it.  The GPL doesn't give anything to users, it
> takes some control away from users and gives it to the author of the
> code.
> 


Re: User locks code

From
"Oliver Elphick"
Date:
Bruce Momjian wrote:
... >Yes, that is probably it.  The GPL doesn't give anything to users, it >takes some control away from users and
givesit to the author of the >code.
 

Correction - it takes away from the *distributor* of binaries the right to
give users fewer rights than he has.  If he doesn't distribute, he can do what 
he likes.

I'm sorry to be pedantic!  We need to be clear about that because Microsoft
are trying to spread FUD about it. 


From the project's point of view, it is probably a bad idea to accept code
under any licence other than BSD.  That can only lead to confusion among
users and distributors alike and may led to inadvertent violation of the
GPL by those who don't notice that it is has been used.

-- 
Oliver Elphick                                Oliver.Elphick@lfix.co.uk
Isle of Wight                              http://www.lfix.co.uk/oliver
PGP: 1024R/32B8FAA1: 97 EA 1D 47 72 3F 28 47  6B 7E 39 CC 56 E4 C1 47
GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839  932A 614D 4C34 3E1D 0C1C
========================================   "I saw in the night visions, and, behold, one like the      Son of man came
withthe clouds of heaven, and came to     the Ancient of days, and they brought him near before      him. And there was
givenhim dominion, and glory, and      a kingdom, that all people, nations, and languages,      should serve him; his
dominionis an everlasting      dominion, which shall not pass away, and his kingdom      that which shall not be
destroyed."                                       Daniel 7:13,14
 




RE: User locks code

From
"Mikheev, Vadim"
Date:
> So, rather than going over everone's IANAL opinons about mixing
> licenses, let's just let Massimo know that it'd just be a lot
> easier to PostgreSQL/BSD license the whole thing, if he doesn't
> mind too much.

Yes, it would be better.

Vadim


Re: User locks code

From
Bruce Momjian
Date:
> Bruce Momjian wrote:
> ...
> >   >Yes, that is probably it.  The GPL doesn't give anything to
> >   users, it takes some control away from users and gives it to
> >   the author of the code.
> 
> Correction - it takes away from the *distributor* of binaries
> the right to give users fewer rights than he has.  If he doesn't
> distribute, he can do what he likes.

That is not totally true.  While it prevents him from distributing code
with fewer rights than the GPL code he received, he loses distribution
rights on the code he writes as well.  That is the _viral_ nature of the
GPL that MS was talking about.

I know it is not fun to hear these GPL issues, but it is a valid
concern.

> I'm sorry to be pedantic!  We need to be clear about that because
> Microsoft are trying to spread FUD about it.

I was even more pedantic.  :-)

> >From the project's point of view, it is probably a bad idea to accept code
> under any license other than BSD.  That can only lead to confusion
> among users and distributors alike and may led to inadvertent
> violation of the GPL by those who don't notice that it is has
> been used.

Considering that we link the backend against libreadline if it exists
(even though it isn't needed by the backend), we already have quite a
bit of confusion.  Only libedit can be used freely for line editing,
i.e. psql.

-- Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026
 


Re: User locks code

From
Ian Lance Taylor
Date:
Hannu Krosing <hannu@tm.ee> writes:

> I know that Compaq was forced to do a clean-room re-engineering of PC
> BIOS 
> (two teams - the dirti one with access to real bios athat does
> description 
> and testin and the clean team to write the actual code so that they can 
> prove they did not "steal" even if the result is byte-by-byte simila)
> for 
> similar reasons

Compaq wasn't forced to do this.  They did it on the basis that
following this complex procedure would guarantee that they would win
if it came to a court case (which it did not).  But there is no way to
tell whether a simpler procedure would not win in court.

The GPL is a copyright license.  Copyrights, unlike patents, only put
limitations on derived works.  If you independently write the same
novel, and you can prove in court that you never saw the original
novel, you are not guily of violating copyright.  That's why Compaq
followed the procedure they did (and it's why Pierre Menard was not
guilty of copyright infringement).

But that's novels.  As far as I know, there is no U.S. law, and there
are no U.S. court decisions, determining when one program is a
derivative of another.  If you read a novel, and write a novel with
similar themes or characters, you've infringed.  However, there is
less protection for functional specifications, in which there may be
only one way to do something.  When does a computer program infringe?
Nobody knows.

Ian


Re: User locks code

From
Bruce Momjian
Date:
> Regarding the licencing of the code, I always release my code under GPL,
> which is the licence I prefer, but my code in the backend is obviously
> released under the original postgres licence. Since the module is loaded
> dynamically and not linked into the backend I don't see a problem here.
> If the licence becomes a problem I can easily change it, but I prefer the
> GPL if possible.

We just wanted to make sure the backend changes were not under the GPL.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026
 


Re: User locks code

From
Massimo Dal Zotto
Date:
> > Tom Lane wrote:
> > > 
> > > I definitely agree with Vadim here: it's fairly silly that the
> > > contrib userlock code is GPL'd, when it consists only of a few dozen
> > > lines of wrapper for the real functionality that's in the main backend.
> > 
> 
> I was incorrect in something I said to Vadim.  I said stored procedures
> would have to be released if linked against a GPL'ed backend.  They have
> to be released only if they are in C or another object file linked into
> the backend.  PlpgSQL or SQL functions don't have to be released because
> their code is "loaded" into the backend as a script, not existing in the
> backend binary or required for the backend to run.
> 
> > Maybe it makes Massimo feel good ? It seems a worhty reason to me, as 
> > he has contributed a lot of useful stuff over the time.
> 
> Yes, that is probably it.  The GPL doesn't give anything to users, it
> takes some control away from users and gives it to the author of the
> code.

I have to disagree here. GPL gives users the assurance that code can't be
modified and distributed under a more restrictive licence, for example with
no source code available or restrictions on commercial use.

On the contrary BSD doesn't guarantee almost anything on this sense.
Think about what happened with the original Kerberos and the microsoft
version which was deliberately modified to prevent compatibilty with
non microsoft implementations. This has been possible only because it
was released under BSD licence. This why I prefer GPL over BSD.

I choosed to release my code under GPL because I'm more concerned with
freedom of software than with commercial issues of it.

Anyway, please stop this thread. I will change the licence of my contrib
code and make it compatible with postgres licence.

After all, as someone poited out, it is a very trivial code and I don't
really care about what people is doing with it.

> > I really think that mixing licences inside one program is bad, if not
> > for 
> > any other reason then for confusing people and making them have
> > discussions 
> > like this.
> 
> Yes, the weird part is that the BSD license is so lax (don't sue us)
> that it is the addition of the GPL that changes the affect of the
> license.  If you added a BSD license to a GPL'ed piece of code, the
> effect would be near zero.
> 
> > > Besides, anyone who actually wanted to use the userlock code would need
> > > only to write their own wrapper functions to get around the GPL license.
> > 
> > This is a part of copyright law that eludes me - can i write a
> > replacement
> > function for something so simple that it can essentially be done in one 
> > way only (like incrementing a value by one) ?
> 
> Sure, if you don't cut and paste the code line by line, or retype the
> code while staring at the previous version.  That is how Berkeley got
> unix-free version of the BSD operating system.  However, the few places
> where they lazily copied got them in trouble.
> 
> -- 
>   Bruce Momjian                        |  http://candle.pha.pa.us
>   pgman@candle.pha.pa.us               |  (610) 853-3000
>   +  If your life is a hard drive,     |  830 Blythe Avenue
>   +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
> 
> http://www.postgresql.org/users-lounge/docs/faq.html
> 

-- 
Massimo Dal Zotto

+----------------------------------------------------------------------+
|  Massimo Dal Zotto               email: dz@cs.unitn.it               |
|  Via Marconi, 141                phone: ++39-0461534251              |
|  38057 Pergine Valsugana (TN)      www: http://www.cs.unitn.it/~dz/  |
|  Italy                             pgp: see my www home page         |
+----------------------------------------------------------------------+


Re: [OT] Re: User locks code

From
Hannu Krosing
Date:
Serguei Mokhov wrote:
> 
> and why the PostgreSQL project originally is being
> released under the BSD-like license? Just curious...

Berkeley usually releases their free projects under BSD licence ;)

There have been some discussion about changing it, but it has never got 
enough support.

--------------
Hannu