Re: [OT] Re: [HACKERS] User locks code
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 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] User locks code
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 [EMAIL PROTECTED] | (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: [EMAIL PROTECTED] | | Via Marconi, 141phone: ++39-0461534251 | | 38057 Pergine Valsugana (TN) www: http://www.cs.unitn.it/~dz/ | | Italy pgp: see my www home page | +--+ ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] User locks code
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 [EMAIL PROTECTED] | (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
Re: [HACKERS] User locks code
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 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[OT] Re: [HACKERS] User locks code
- Original Message - From: Bruce Momjian [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[OT] Re: [HACKERS] User locks code
- Original Message - From: Bruce Momjian [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
RE: [HACKERS] User locks code
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 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] User locks code
Bruce Momjian [EMAIL PROTECTED] 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 [EMAIL PROTECTED] | (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 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
RE: [OT] Re: [HACKERS] User locks code
Because the code we got from Berkeley was BSD licensed, we can't change it, and because many of us like the BSD license better because we don't want to require them to release the source code, we just want them to use PostgreSQL. And we think they will release the source code eventually anyway. And we think that no one will try to fork and commercialize server code - todays, when SAP InterBase open their DB code, it seems as no-brain. Vadim ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] User locks code
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. 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[EMAIL PROTECTED] 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 with the clouds of heaven, and came to the Ancient of days, and they brought him near before him. And there was given him dominion, and glory, and a kingdom, that all people, nations, and languages, should serve him; his dominion is an everlasting dominion, which shall not pass away, and his kingdom that which shall not be destroyed. Daniel 7:13,14 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] User locks code
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. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
RE: [HACKERS] User locks code
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 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] User locks code
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 [EMAIL PROTECTED] To: [EMAIL PROTECTED] 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 [EMAIL PROTECTED] Copyright (C) 1999, Massimo Dal Zotto [EMAIL PROTECTED] 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 user locks 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 the program doesn't freeze and the user simply knows it can't use that object. 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: [EMAIL PROTECTED] | | Via Marconi, 141phone: ++39
RE: [HACKERS] User locks code
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 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] User locks code
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 [EMAIL PROTECTED] | (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 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
RE: [HACKERS] User locks code
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 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] User locks code
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 [EMAIL PROTECTED] | (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 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
RE: [HACKERS] User locks code
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 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] User locks code
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 [EMAIL PROTECTED] | (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 4: Don't 'kill -9' the postmaster
RE: [HACKERS] User locks code
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 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] User locks code
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 [EMAIL PROTECTED] | (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 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] User locks code
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 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] User locks code
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 [EMAIL PROTECTED] | (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
Re: [HACKERS] User locks code
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 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
RE: [HACKERS] User locks code
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 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] User locks code
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 [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
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 [EMAIL PROTECTED]
Copyright (C) 1999, Massimo Dal Zotto [EMAIL PROTECTED]
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 [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
RE: [HACKERS] User locks code
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 [EMAIL PROTECTED] To: [EMAIL PROTECTED] 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 [EMAIL PROTECTED] Copyright (C) 1999, Massimo Dal Zotto [EMAIL PROTECTED] 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 [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] User locks code
1. Just noted this in contrib/userlock/README.user_locks:
User locks, by Massimo Dal Zotto [EMAIL PROTECTED]
Copyright (C) 1999, Massimo Dal Zotto [EMAIL PROTECTED]
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 [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
