Re: [HACKERS] Patent issues and 8.1
At 2005-02-07 12:28:34 -0500, [EMAIL PROTECTED] wrote: > > > There was some mention of an upgrade tool which would avoid the need > > for a dump/restore - did that idea die? > > No, but I don't see anyone volunteering to work on it now I like the idea of having a working pg_upgrade (independent of the ARC patent issue), so I don't mind working on it. I'll have a look at the code sometime this week. -- ams ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Patent issues and 8.1
Andrew Dunstan <[EMAIL PROTECTED]> writes: > Jan Wieck wrote: >> Then we better make sure that 8.0 -> 8.1 does not require dump&reload. > There was some mention of an upgrade tool which would avoid the need for > a dump/restore - did that idea die? No, but I don't see anyone volunteering to work on it now --- much less to make it robust and reliable in the next two months, which is what would have to happen to make it a useful answer in the timeframe we need. At the moment I think that the most sane way to proceed is to back-patch one of the 2Q variants I posted into 8.0.*, so as to get out of the patent issue in that branch with minimum effort, and then proceed with a "normal" development cycle for 8.1. The discussions currently going on about the bufmgr are focusing on abandoning LRU/ARC/2Q entirely in favor of something that requires only local state updates, so it seems a bit pointless to expend a major amount of work on that line of code. regards, tom lane ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Patent issues and 8.1
Jan Wieck wrote: No, as an 8.0.x is mean to be for minor changes/fixes/improvements ... 'addressing a patnt conflict', at least in ARC's case, is a major change, which is why we are looking at a short dev cycle for 8.1 ... Then we better make sure that 8.0 -> 8.1 does not require dump&reload. However unlikely we judge the patent problem to actually bite people, we cannot force 8.0.x users into a dump&reload upgrade by not providing a backport when it happens. There was some mention of an upgrade tool which would avoid the need for a dump/restore - did that idea die? cheers andrew ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Patent issues and 8.1
On 1/25/2005 6:23 PM, Marc G. Fournier wrote: On Tue, 25 Jan 2005, Bruce Momjian wrote: pgman wrote: Not yet --- I suggested it but didn't get any yeas or nays. I don't feel this is solely core's decision anyway ... what do the assembled hackers think? I am not in favor of adjusting the 8.1 release based solely on this patent issue. I think the probability of the patent being accepted and enforced against anyone using PostgreSQL to be very unlikely. I would also like to come up with a procedure that would scale to any other patent problems we might have. What if someone finds another patent problem during 8.1 beta? Do we shorten the 8.2 development cycle too? What I would like to do is to pledge that we will put out an 8.0.X to address any patent conflict experienced by our users. This would include ARC or anything else. This way we don't focus just on ARC but have a plan for any patent issues that appear, and we don't have to adjust our development cycle until an actual threat appears. One advantage we have is that we can easily adjust our code to work around patented code by just installing a new binary. (Patents that affect our storage format would be more difficult. A fix would have to perhaps rewrite the on-disk data.) One problem in working around the GIF format patent is that you had to create a file that was readable by many of the existing GIF readers. With PostgreSQL, only we read our own data files so we can more easily make adjustments to avoid patents. I did not see any reaction to my ideas above. Is this a good plan? No, as an 8.0.x is mean to be for minor changes/fixes/improvements ... 'addressing a patnt conflict', at least in ARC's case, is a major change, which is why we are looking at a short dev cycle for 8.1 ... Then we better make sure that 8.0 -> 8.1 does not require dump&reload. However unlikely we judge the patent problem to actually bite people, we cannot force 8.0.x users into a dump&reload upgrade by not providing a backport when it happens. Jan Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # ---(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] Patent issues and 8.1
A new organization called the "Software Freedom Law Center" was announced yesterday; that seems like it may be one of the best places open-source groups could go for questions like this ARC pending patent. Eben Moglen (The FSF's main lawyer and Columbia Law prof), Diane Peters (OSDL's general counsel), and Lawrence Lesseg (Stanford law prof behind Creative Commons) are behind this organization; so it seems to have pretty good credentials. http://news.com.com/2100-7344_3-5557962.html "The center said in a statement that it will employ two full-time intellectual property attorneys, who will help provide consulting services to nonprofit open-source organizations. The staff count is expected to expand to four later in 2005. The help they provide could include training lawyers, supporting litigation, dealing with licensing problems and keeping managing contributions to open-source projects, the center said. " ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] [pgsql-hackers] Patent issues and 8.1
Marc, > alot smoother today then it went yesterday ... and faster ... but, then > again, *most* clients use <256MB of storage, so moving their VM around > takes no time ... svr1 is @ ~13G :) Something like 3G is justin's mailbox > alone ... and i miscalculated how long it would take to move it back over > to neptune :( I doubt that's intentional, why don't you ask him to truncate it? I noticed that you used to grant @postgresql.org addresses as "unlimited", I changed the default to 5MB, which is what all the regional contacts now have. -- Josh Berkus Aglio Database Solutions San Francisco ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] [pgsql-hackers] Patent issues and 8.1
On Mon, 31 Jan 2005, Josh Berkus wrote: Marc, And to be perfectly frank, I was mostly thinking of Marc when I said that. Sorry, that was uncharitable. I meant that (at the time) you were panicking. Wait, I've not panic'd about all of this at any point ... the only 'chicken little' comment I made had to do with everyone panicking about a patent that doesn't yet exist, and comparing that to "chicken little and his 'the sky is falling'" ... *scratch head* Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(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] [pgsql-hackers] Patent issues and 8.1
On Mon, 31 Jan 2005, Josh Berkus wrote: Now you have something different to panic about. How goes the server shuffle? alot smoother today then it went yesterday ... and faster ... but, then again, *most* clients use <256MB of storage, so moving their VM around takes no time ... svr1 is @ ~13G :) Something like 3G is justin's mailbox alone ... and i miscalculated how long it would take to move it back over to neptune :( Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [pgsql-hackers] Patent issues and 8.1
Josh Berkus wrote: Guys, BTW, if you hadn't guessed, that comment was supposed to be off-list. Unfortunately, I discovered a bug with KMail and list management, the hard way ... Sigh.Just in case anyone wants to know, KMail 1.5.1 + has a bug where, if you have list management turned on, it sometimes sends stuff to the list instead of the To: line you see on the screen. Dammit! Any other Linux-friendly mail GUIs that have list management features and don't have this problem? Evolution does although I haven't tried it in a while. J -- Command Prompt, Inc., your source for PostgreSQL replication, professional support, programming, managed services, shared and dedicated hosting. Home of the Open Source Projects plPHP, plPerlNG, pgManage, and pgPHPtoolkit. Contact us now at: +1-503-667-4564 - http://www.commandprompt.com begin:vcard fn:Joshua D. Drake n:Drake;Joshua D. org:Command Prompt, Inc. adr:;;PO Box 215;Cascade Locks;Oregon;97014;USA email;internet:[EMAIL PROTECTED] title:Consultant tel;work:503-667-4564 tel;fax:503-210-0334 note:Command Prompt, Inc. is the largest and oldest US based commercial PostgreSQL support provider. We provide the only commercially viable integrated PostgreSQL replication solution, but also custom programming, and support. We authored the book Practical PostgreSQL, the procedural language plPHP, and adding trigger capability to plPerl. x-mozilla-html:FALSE url:http://www.commandprompt.com/ version:2.1 end:vcard ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] [pgsql-hackers] Patent issues and 8.1
Marc, > And to be perfectly frank, I was mostly thinking of Marc when I said that. Sorry, that was uncharitable. I meant that (at the time) you were panicking. Now you have something different to panic about. How goes the server shuffle? -- Josh Berkus Aglio Database Solutions San Francisco ---(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] [pgsql-hackers] Patent issues and 8.1
Andrew, > On Thu, Jan 27, 2005 at 10:39:52AM -0800, Josh Berkus wrote: > > Thanks. As you know, I'm getting a little sick of the chicken little > > act among many of the -hackers > > I think this is a little bit of a mischaracterisation. Afilias is > already a customer of IBM. BTW, if you hadn't guessed, that comment was supposed to be off-list. Unfortunately, I discovered a bug with KMail and list management, the hard way ... And to be perfectly frank, I was mostly thinking of Marc when I said that. -- Josh Berkus Aglio Database Solutions San Francisco ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] [pgsql-hackers] Patent issues and 8.1
Guys, > BTW, if you hadn't guessed, that comment was supposed to be off-list. > Unfortunately, I discovered a bug with KMail and list management, the hard > way ... Sigh.Just in case anyone wants to know, KMail 1.5.1 + has a bug where, if you have list management turned on, it sometimes sends stuff to the list instead of the To: line you see on the screen. Dammit! Any other Linux-friendly mail GUIs that have list management features and don't have this problem? -- Josh Berkus Aglio Database Solutions San Francisco ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] [pgsql-hackers] Patent issues and 8.1
On Saturday 29 January 2005 11:33, Tom Lane wrote:
> Robert Treat <[EMAIL PROTECTED]> writes:
> > I'm not mischarecterizing, I just feel that putting out an lru based
> > 8.0.x release is such a bad idea that I'd rather do (1) than gamble on
> > (2).
>
> I don't understand why you think it's such a bad idea. We do have the
> problem of getting adequate testing, but I think the answer to that
> is to put the same patch into HEAD as well.
>
The combination of inadequate testing, making support more difficult, and
general all around confusion that beta/rc's for a revision level release are
sure to cause. Not to mention that if the patent ever does materialize into a
problem, the scope of that problem will be that much greater the longer we
wait.
> > We can branch 8.1 and 8.2 now, with 2month dev planned for 8.1 and a
> > 12 month dev for 8.2 and go about things.
>
> I will resist that idea strongly. We have no experience as a community
> with managing multiple active development branches, and I feel certain
> that we'd mess it up (eg, commit things into the wrong branch, or fail
> to commit things into both branches that need to be in both). Case in
> point: Teodor has already, without discussion, committed 8.1 changes in
> tsearch2 that should force an initdb. If we were taking the idea of a
> backward-compatible 8.1 seriously we'd have to make him back that out of
> 8.1.
I think this is a false case since right now we are hanging in limbo, with
people unsure of what is proper to commit into what branch. If there had
been an official announcement that no initdb level changes were to go into
8.1 I think we'd be ok.
> I can't see trying to ride herd on all the committers to make sure
> no one unintentionally breaks file-level compatibility over a whole dev
> cycle, even a short one.
>
I think the key is to put someone in charge of either 8.1 or 8.2 and let them
be the primary gatekeeper for that release. It can work either way... people
develop against 8.1 and we have an 8.2 gatekeeper(s) responsible for patching
forward any new commits into 8.2 and handling file-level incompatible feature
commits. Conversly we can have folks develop against 8.2 and have someone in
charge of backpatching any non file-level incompatible changes backwards and
the ARC changes.
There are other upsides to this as well. If we could do this now it would
help move us to the ability to keep feature development going year round.
Rather than having to stop 4-5 months every year to do beta we could create a
new branch during beta and let people continue on with that... we already had
some rumblings of that idea during the 8.0 beta cycle, this would give us a
good test run.
--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] [pgsql-hackers] Patent issues and 8.1
Robert Treat <[EMAIL PROTECTED]> writes: > I'm not mischarecterizing, I just feel that putting out an lru based 8.0.x > release is such a bad idea that I'd rather do (1) than gamble on (2). I don't understand why you think it's such a bad idea. We do have the problem of getting adequate testing, but I think the answer to that is to put the same patch into HEAD as well. > We can branch 8.1 and 8.2 now, with 2month dev planned for 8.1 and a > 12 month dev for 8.2 and go about things. I will resist that idea strongly. We have no experience as a community with managing multiple active development branches, and I feel certain that we'd mess it up (eg, commit things into the wrong branch, or fail to commit things into both branches that need to be in both). Case in point: Teodor has already, without discussion, committed 8.1 changes in tsearch2 that should force an initdb. If we were taking the idea of a backward-compatible 8.1 seriously we'd have to make him back that out of 8.1. I can't see trying to ride herd on all the committers to make sure no one unintentionally breaks file-level compatibility over a whole dev cycle, even a short one. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] [pgsql-hackers] Patent issues and 8.1
On Friday 28 January 2005 12:36, Josh Berkus wrote:
> Robert,
>
> > Read the law... willful vs. unknown infringement are two different
> > things.
>
> We're not infringing anything, yet. That's a *pending* patent.
>
*sigh* Thats understood. But you were using the counter-argument that we
might be infringing on patents we know nothing about now so why treat this
one any different. I'm pointing out this one would be different because we
know about it and the law treats these things seperatly.
> > Um... thats the way our legal system works. You could do that to any
> > project if you had a patent they were infringing upon no matter how
> > stoic they tried to be about it. (By our I mean the U.S. system)
>
> You're not following me. Imagine this:
> 1) Pervasive/Fujistsu/SRA/Mammoth PostgreSQL steals some big clients from
> Obsolete Proprietary Database Company (OPDC).
> 2) OPDC has someone dig through their piles of patents and finds something
> that looks like it might infringe on something PostgreSQL does.
> 3) OPDC gets a blogger or similar to post something "And in the latest
> patent infringment news ..."
> 4) -Hackers hears about it and we derail development for another 3 months
> in order to work around the patent.
> Net Cost to OPDC: couple $thousand, to delay a PG release by 3+ months.
>
> What's kept patent litigation from being used against OSS projects so far
> is the bad PR that would attach, the potential cost of litigation, the
> possibility of having the patent invalidated, and the dubvious prospect of
> compensation. But if a competitor can disrupt an OSS project with a
> *threatened* patent, then the cost is minimal and the effect is huge.
>
> We will face this situation again -- at least, until software patents go
> away -- and both I and Bruce feel that it's important to set a precedent in
> dealing with them because you can bet this discussion is being read by
> people who are not in favor of the spread of PostgreSQL.This isn't just
> about the ARC patent, it's about the next one after that.
>
I guess I don't understand your rational here? You want to set a precendent
that the PGDG only responds to lawsuits? Seems we should be willing to
address anyones patent concerns in a resonable manner... but that will
depend on the size of the changes needed and what point in the development
cycle we are. This is a good size change and it comes at a time in the dev
cycle when we have all our options open (it would be different if we were 4
months in with all kinds of new things already added) and it's a feature that
*we all want to change anyway* so why not be agressive about it?
> > FWIW I've really only been advocating
>
> BTW, my last post wasn't specifically addressed at you, but at the
> viewpoint that we should drop everything and work on the ARC replacement to
> get it out the door in 4 months.
>
> > that we don't do the change in a
> > patch branch, which I'm afraid the "do nothing till the lawyers show up"
> > plan would eventually lead to. We wouldn't normally do things that way
> > on technical grounds, so I'd prefer not to be forced into doing things
> > that way for other reasons; enough so that I think we ought to have a
> > plan to address it now.
>
> It's not a choice between doing something and doing nothing; you're
> mischaracterizing. It's a choice between:
>
> 1) Shall we begin development immediately on an 8.1 which does not include
> the ARC code and can be upgraded without initdb, for plans to release this
> version in 4 months or less?
>
> 2) Shall we work our regular 1-year development cycle, with plans to
> replace ARC with an improved memory management approach as part of the
> features of 8.1, keeping a reversion-to-LRU patch in reserve in case we
> have to release it as a patch in the 8.0.x series?
>
> I advocate (2), partly because I don't believe that (1) is really possible
> for us. When's the last time we did a fast release? What I do advocate
> doing *now* is:
>
I'm not mischarecterizing, I just feel that putting out an lru based 8.0.x
release is such a bad idea that I'd rather do (1) than gamble on (2).
Honestly I don't think anything will ever come of this, but if things go
spectacularly bad, the fewer arc-based releases out there the better. Not
to mention that the only downside I have seen to (1) is that people think it
will disrupt development too much but I don't buy that. We can branch 8.1
and 8.2 now, with 2month dev planned for 8.1 and a 12 month dev for 8.2 and
go about things. This would also have the advantage of pushing out a lot of
loose ends a bit sooner (do we really want to wait a year for things like
typo friendly psql?) as people get more understanding of the new features
made in 8.0.
--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
h
Re: [HACKERS] Patent issues and 8.1
"Greg Sabino Mullane" <[EMAIL PROTECTED]> writes: > Spending time on this is silly, IMO, unless there is a technical reason > why the feature should be replaced. Well, people can validly have different opinions on how critical it is to dodge the upcoming patent (and surely whether you live in the US or not affects your viewpoint). But as to the second part of your comment, the fact is that the ARC buffer management code has been underwhelming and we were already looking around for something better. I believe Jan already admitted that his original testing was flawed and that the algorithm is not so much better than LRU as he thought. We are also staring at the fact that ARC is not at all helpful when it comes to the problem of reducing contention for the BufMgrLock. It uses an inherently centralized, serialized data structure and the operations it requires aren't notably cheap. So I was already feeling dissatisfied even before the patent issue came up, and I'm all for getting rid of ARC as soon as we can find (and test) something better. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Patent issues and 8.1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > Read the law... willful vs. unknown infringement are two > different things. You can't infringe on a non-existent patent. > FWIW I've really only been advocating that we don't do the change in a > patch branch, which I'm afraid the "do nothing till the lawyers show up" > plan would eventually lead to. It's not "do nothing till the lawyers show up." At the very least, it's "do nothing until it actually becomes a patent." There are 1000s of pending patents out there. The bar is very low: all it takes is some money and some paperwork. Proving that it is novel and new is the tough part, and there is no guarantee that this particular one will get to that level. If it does, IBM could certainly donate it, or let the project use it, or decide that our implementation is sufficiently different. At any rate, they are not likely to go after an open source project, even if via our "customers." If and when they do, that's when we react, the same way with do with security fixes: make new branches, and release them. We look good, IBM looks bad, and we get lots of free publicity. Spending time on this is silly, IMO, unless there is a technical reason why the feature should be replaced. - -- Greg Sabino Mullane [EMAIL PROTECTED] PGP Key: 0x14964AC8 200501282155 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -BEGIN PGP SIGNATURE- iD8DBQFB+vtuvJuQZxSWSsgRAnB8AKDnUsQM7xb1tRF93ehT05xg6Bf6TwCeOYn9 JdP4di03yzuSB9aaVskXb5g= =U9HF -END PGP SIGNATURE- ---(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] [pgsql-hackers] Patent issues and 8.1
Robert, > Read the law... willful vs. unknown infringement are two different > things. We're not infringing anything, yet. That's a *pending* patent. > Um... thats the way our legal system works. You could do that to any > project if you had a patent they were infringing upon no matter how > stoic they tried to be about it. (By our I mean the U.S. system) You're not following me. Imagine this: 1) Pervasive/Fujistsu/SRA/Mammoth PostgreSQL steals some big clients from Obsolete Proprietary Database Company (OPDC). 2) OPDC has someone dig through their piles of patents and finds something that looks like it might infringe on something PostgreSQL does. 3) OPDC gets a blogger or similar to post something "And in the latest patent infringment news ..." 4) -Hackers hears about it and we derail development for another 3 months in order to work around the patent. Net Cost to OPDC: couple $thousand, to delay a PG release by 3+ months. What's kept patent litigation from being used against OSS projects so far is the bad PR that would attach, the potential cost of litigation, the possibility of having the patent invalidated, and the dubvious prospect of compensation. But if a competitor can disrupt an OSS project with a *threatened* patent, then the cost is minimal and the effect is huge. We will face this situation again -- at least, until software patents go away -- and both I and Bruce feel that it's important to set a precedent in dealing with them because you can bet this discussion is being read by people who are not in favor of the spread of PostgreSQL.This isn't just about the ARC patent, it's about the next one after that. > FWIW I've really only been advocating BTW, my last post wasn't specifically addressed at you, but at the viewpoint that we should drop everything and work on the ARC replacement to get it out the door in 4 months. > that we don't do the change in a > patch branch, which I'm afraid the "do nothing till the lawyers show up" > plan would eventually lead to. We wouldn't normally do things that way > on technical grounds, so I'd prefer not to be forced into doing things > that way for other reasons; enough so that I think we ought to have a > plan to address it now. It's not a choice between doing something and doing nothing; you're mischaracterizing. It's a choice between: 1) Shall we begin development immediately on an 8.1 which does not include the ARC code and can be upgraded without initdb, for plans to release this version in 4 months or less? 2) Shall we work our regular 1-year development cycle, with plans to replace ARC with an improved memory management approach as part of the features of 8.1, keeping a reversion-to-LRU patch in reserve in case we have to release it as a patch in the 8.0.x series? I advocate (2), partly because I don't believe that (1) is really possible for us. When's the last time we did a fast release? What I do advocate doing *now* is: a) someone (Simon? Sean? Neil? Jan?) should start hacking on a better-than-ARC buffer manager to have it for 8.1, and b) we should build an 8.0.1 with Neil's Revert-to-LRU patch, upload it to OSDL, and start hammering on it so that it will be tested in case we need it (and if there's no loss of performance or stability, maybe drop it in the update stream regardless of patent status). I also suggest that we might want to hit up one of the several well-funded parties involved in PostgreSQL, who have staff attorneys, for an opinion on the whole business, and some insight into what proprietary software companies do. That would be Pervasive, Fujitsu (assuming that AU has software patents, I don't know), OSDL, and CMD. Heck, there will be a panel of OSS attorneys at the Enterprise Linux Summit; I can ask them but of course it won't be an actual opinion unless money changes hands. -- Josh Berkus Aglio Database Solutions San Francisco ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] [pgsql-hackers] Patent issues and 8.1
On Thu, 2005-01-27 at 12:51, Josh Berkus wrote:
> We don't *have* to do anything when the patent is granted. When we *have*
> to
> do something is when IBM sends a cease-and-desist letter to a PostgreSQL
> user. Not before.
>
With that attitude we don't have to do anything even then. We have a
good number of users that this patent claim will be unenforceable
on...right? We have the option of dealing with this now on our own
terms... if we gamble and lose we may have to deal with it in less
favorable conditions.
> Now, if one of our commercial supporting companies is worried enough about
> this to do something -- such as funding a hacker for a 3-month intensive
> better-than-ARC development stint -- then let them step up to the plate.
> Many of our programmers are happy to accept commercial development dollars
> for what is a commercial concern. Let's not steer development based on
> protecting what we think is protecting our commercial sponsors, when they
> haven't even asked us!
>
I'm not sure if your glossing over this on purpose or your just unaware,
but it is not just commercial support companies that will be getting
those letters if IBM ever heads that route. (I'd agree that I don't
think they will, but let's not kid ourselves if they do)
> Like *any* other piece of major software, we probably infringe on 50
> different
> patents which we don't know about, held by a variety of parties.
Read the law... willful vs. unknown infringement are two different
things.
> If we let
> this one *potential* patent panic us into a response we may regret later --
> such as derailing 8.1 development, or releasing an insufficiently tested new
> version -- then some other company will threaten us with patents with
> malicious intent to watch us jump and scramble again.
>
Um... thats the way our legal system works. You could do that to any
project if you had a patent they were infringing upon no matter how
stoic they tried to be about it. (By our I mean the U.S. system)
> Attorneys have already said that Linux infringes several dozen outstanding
> patents. Do you see Linus suddenly overhauling the kernel? Dropping
> everthing and rushing a non-infringing, under-tested 2.8 to release? No, you
> don't.
>
Well, I suppose if we had someone's who job was supported by dozens of
multi-billion dollar corporations who all had patent portfolio's that
totaled into the thousands we'd probably have more legs to stand on, but
we don't so the WWLD plan may not be best for us.
FWIW I've really only been advocating that we don't do the change in a
patch branch, which I'm afraid the "do nothing till the lawyers show up"
plan would eventually lead to. We wouldn't normally do things that way
on technical grounds, so I'd prefer not to be forced into doing things
that way for other reasons; enough so that I think we ought to have a
plan to address it now.
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Patent issues and 8.1
On Thu, 27 Jan 2005, Robert Treat wrote: On Thursday 27 January 2005 20:47, Tom Lane wrote: Robert Treat <[EMAIL PROTECTED]> writes: On Thursday 27 January 2005 10:27, Tom Lane wrote: Ordinarily I would agree with you, but what happens to someone who is still running 8.0.* when IBM's patent gets issued? This is a straw-man, since nothing stops people from running 8.0.0 even if the replacement come in 8.0.1 I don't think so. It's not our responsibility if someone doesn't take advantage of an available update. But it is our responsibility if no update is available. The straw-man is that this needs to happen in 8.0.x rather than 8.1, IMHO. the 8.0.x branch is already released software, and is no longer being developed, prior to any patent happening ... the ARC changes will by no means be a "bug fix", nor minor, and aren't appropriate for back patching to any of the releases, including 8.0.x ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(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] Patent issues and 8.1
On Thursday 27 January 2005 20:47, Tom Lane wrote:
> Robert Treat <[EMAIL PROTECTED]> writes:
> > On Thursday 27 January 2005 10:27, Tom Lane wrote:
> >> Ordinarily I would agree with you, but what happens to someone who is
> >> still running 8.0.* when IBM's patent gets issued?
> >
> > This is a straw-man, since nothing stops people from running 8.0.0
> > even if the replacement come in 8.0.1
>
> I don't think so. It's not our responsibility if someone doesn't take
> advantage of an available update. But it is our responsibility if no
> update is available.
>
The straw-man is that this needs to happen in 8.0.x rather than 8.1, IMHO.
--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
Re: [HACKERS] Patent issues and 8.1
Robert Treat <[EMAIL PROTECTED]> writes: > On Thursday 27 January 2005 10:27, Tom Lane wrote: >> Ordinarily I would agree with you, but what happens to someone who is >> still running 8.0.* when IBM's patent gets issued? > This is a straw-man, since nothing stops people from running 8.0.0 > even if the replacement come in 8.0.1 I don't think so. It's not our responsibility if someone doesn't take advantage of an available update. But it is our responsibility if no update is available. regards, tom lane ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Patent issues and 8.1
On Thursday 27 January 2005 10:27, Tom Lane wrote:
> Robert Treat <[EMAIL PROTECTED]> writes:
> > I don't think it is worth breaking the expectation that only minor
> > changes get committed in revision level releases even with a beta.
>
> Ordinarily I would agree with you, but what happens to someone who is
> still running 8.0.* when IBM's patent gets issued? (It seems very
> likely to me that the patent will be issued before 8.0 disappears from
> the wild.) We really have to have an answer for that, and that means
> that an algorithm change has to get back-patched into 8.0.*.
>
This is a straw-man, since nothing stops people from running 8.0.0 even if the
replacement come in 8.0.1
> I'm coming around to the viewpoint that we should do this as a
> back-patch rather than try to release a file-compatible 8.1. The reason
> is that people who are hesitant to move up to a new release are hesitant
> not only because of dump/reload costs; they also worry about whether a
> new version will break their existing applications. If 8.1 has a pile
> of new features, or even simple behavioral changes such as flipping the
> with_oids default, then it will look like a hazard to them even without
> a dump/reload cycle.
>
Some people get scared of changes between even minor revision releases even
when we tell them it is safe to do. (Of course pushing a change like ARC out
in a minor release isn't going to help do away with that perception) Sticking
to a two-month/no-initdb cycle, I don't think we'll have to worry about
"piles-of-changes" that make things incompatible.
> What's really being debated here is how we can have adequate confidence
> in a change that is admittedly larger than we like to back-patch. It's
> not an unprecedented thing mind you; we have back-patched some fairly
> large bug fixes in the past. But it's a bit galling to be taking any
> such risk for purely legal rather than technical reasons.
>
Especially when it doesn't even effect everyone involved. Or anyone... who
knows, maybe oracle is out submitting prior art and the thing never even gets
granted.
--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
Re: [HACKERS] Patent issues and 8.1
Josh Berkus writes: > No, we're reactive regardless. Proactive would have been to investigate the > ARC paper when it was published for outstanding patent applications, and > again before feature freeze. Or even to have considered the fact that when > an IBM person publishes a paper on new technology, IBM probably has a patent > on it ... they're the largest patent-holder in the world, after all. It's a > little late for that, and would probably not even have been a good idea, lest > we let legal concerns paralyze development. That would actually be a bad idea. As several people have pointed out, actively seeking out patents you may be infringing is risky because it can open you up to liability and that can paralyze development. > We don't *have* to do anything when the patent is granted. When we *have* > to > do something is when IBM sends a cease-and-desist letter to a PostgreSQL > user. Not before. That's untrue. I suggest you disregard all my comments as free legal advice is really only worth what you pay for it. IANAL and all that. But I also suggest you stop giving legal opinions like this. Moreover, the postgres development community is really not the concern here. Users of postgres who are aware of this issue (and many of them are on this list) will be the ones put at risk. -- greg ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] [pgsql-hackers] Patent issues and 8.1
Josh, > >>Bruce is advocating waiting until the Patent has been Granted, instead of > >>doing something about it now, when we know the patent is going through > >> the system (and will likely get granted) ... a "reactive" vs "proactive" > >> response to the problem. > > Very well written Josh. Thanks. As you know, I'm getting a little sick of the chicken little act among many of the -hackers --Josh -- __Aglio Database Solutions___ Josh BerkusConsultant josh@agliodbs.comwww.agliodbs.com Ph: 415-752-2500Fax: 415-752-2387 2166 Hayes Suite 200San Francisco, CA ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] [pgsql-hackers] Patent issues and 8.1
Marc, Tom, Robert, Bruce, et al: > Bruce is advocating waiting until the Patent has been Granted, instead of > doing something about it now, when we know the patent is going through the > system (and will likely get granted) ... a "reactive" vs "proactive" > response to the problem. No, we're reactive regardless. Proactive would have been to investigate the ARC paper when it was published for outstanding patent applications, and again before feature freeze. Or even to have considered the fact that when an IBM person publishes a paper on new technology, IBM probably has a patent on it ... they're the largest patent-holder in the world, after all. It's a little late for that, and would probably not even have been a good idea, lest we let legal concerns paralyze development. > Basically, after the patent is granted, we are going to scramble to get > rid of the ARC stuff, instead of taking the time leadign up to the > granting to get rid of it so that when granted, it isn't something we have > to concern ourselves with ... We don't *have* to do anything when the patent is granted. When we *have* to do something is when IBM sends a cease-and-desist letter to a PostgreSQL user. Not before. Tangentally, but relevant: a few years ago I was facing a potential lawsuit from a customer who had changed management and was suing all their former vendors as a path out of bankruptcy. Never having been sued before, I was inclined to panic. I called a classmate of mine who was a litigation attorney, and retained his services, and asked what I should do. "First off, don't panic," he said. "Have you been served yet?" "um, no" "Then don't worry about it. You may not be served. If you are served, you are likely to be able to get this dismissed. The last thing you want to do is panic and try to bargain with them now; they'll see that you're a softie and go on the attack. You've retained me, that's all you need to do now." (as it turned out, I was never served) Take a look again at the posting by Nicholai -- someone with professional experience in patents. Last I checked, nobody else on this list is a patent attorney, clerk, or IP litigation professional. 1) The patent may not be granted for another year. 2) The patent may never be granted. 3) When/if the patent is granted, its terms may have changed and we may no longer be infringing, *IF* we are now, which I have yet to see an *attorney's* opinion on. 4) IBM may put this patent in its set of GPL patents, since we are not the only OSS project using ARC. This would be a licensing headache for some of our users, but not a catastrophe. 5) Even if IBM does not OSS this patent, they may choose not to enforce it against us or other OSS projects since it would mean massively bad PR for them. Given that we're planning on replacing/overhauling ARC anyway, I really don't see that we need to do more at this time. Except maybe keep Neil's LRU-reversion patch somewhere handy in case we need it, and build a variant version and run it through tests at OSDL to see what it breaks (it would be good to do this anyway to see what, if anything, ARC is gaining us in terms of performance). Now, if one of our commercial supporting companies is worried enough about this to do something -- such as funding a hacker for a 3-month intensive better-than-ARC development stint -- then let them step up to the plate. Many of our programmers are happy to accept commercial development dollars for what is a commercial concern. Let's not steer development based on protecting what we think is protecting our commercial sponsors, when they haven't even asked us! Heck, the idea of a pluggable memory manager tickles my funny bone, even though I don't think such a thing is possible. Like *any* other piece of major software, we probably infringe on 50 different patents which we don't know about, held by a variety of parties. If we let this one *potential* patent panic us into a response we may regret later -- such as derailing 8.1 development, or releasing an insufficiently tested new version -- then some other company will threaten us with patents with malicious intent to watch us jump and scramble again. Attorneys have already said that Linux infringes several dozen outstanding patents. Do you see Linus suddenly overhauling the kernel? Dropping everthing and rushing a non-infringing, under-tested 2.8 to release? No, you don't. -- Josh Berkus Aglio Database Solutions San Francisco ---(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] Patent issues and 8.1
"Marc G. Fournier" <[EMAIL PROTECTED]> writes: > How hard would it be to do as several have suggested already ... abstract > out the ARC/LRU stuff into an API? That was basically my objection to Neil's draft patch: it didn't make any effort to abstract out a cleaner API. I'll try to look into this after we have the security releases out of the way. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Patent issues and 8.1
On Thu, 27 Jan 2005, Tom Lane wrote: What's really being debated here is how we can have adequate confidence in a change that is admittedly larger than we like to back-patch. It's not an unprecedented thing mind you; we have back-patched some fairly large bug fixes in the past. But it's a bit galling to be taking any such risk for purely legal rather than technical reasons. How hard would it be to do as several have suggested already ... abstract out the ARC/LRU stuff into an API? Then, we wouldn't have to remove ARC, per se, only shift it? Wouldn't that be a smaller patch overall? Then, for our non-US users, they could continue to use ARC even after the patent (myself included), while a plug-in replacement could be available for US users? Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(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] Patent issues and 8.1
Robert Treat <[EMAIL PROTECTED]> writes: > I don't think it is worth breaking the expectation that only minor > changes get committed in revision level releases even with a beta. Ordinarily I would agree with you, but what happens to someone who is still running 8.0.* when IBM's patent gets issued? (It seems very likely to me that the patent will be issued before 8.0 disappears from the wild.) We really have to have an answer for that, and that means that an algorithm change has to get back-patched into 8.0.*. I'm coming around to the viewpoint that we should do this as a back-patch rather than try to release a file-compatible 8.1. The reason is that people who are hesitant to move up to a new release are hesitant not only because of dump/reload costs; they also worry about whether a new version will break their existing applications. If 8.1 has a pile of new features, or even simple behavioral changes such as flipping the with_oids default, then it will look like a hazard to them even without a dump/reload cycle. What's really being debated here is how we can have adequate confidence in a change that is admittedly larger than we like to back-patch. It's not an unprecedented thing mind you; we have back-patched some fairly large bug fixes in the past. But it's a bit galling to be taking any such risk for purely legal rather than technical reasons. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Patent issues and 8.1
On Wed, 2005-01-26 at 02:09, Neil Conway wrote:
> Tom Lane wrote:
> > This may be the right path to go for
> > 8.0.* ... but we must NOT suppose that we can just push it out without
> > a full beta test cycle.
>
> Yeah, I think a beta period would be a good idea (not nearly as long as
> the 8.0 beta period was, though).
>
> I think it would be better to have a few weeks of beta prior to 8.0.2
> and resolve the problem here and now, rather than crippling the 8.1
> cycle (as the no-initdb policy would) or waiting for the problem to
> *really* become serious (as the "no action needed now" policy would).
>
I don't think it is worth breaking the expectation that only minor
changes get committed in revision level releases even with a beta. I
especially hate to think about support and tuning information that has
the potential to be quit different depending on if your running 8.0.1 or
8.0.2 or some such division.
I still feel a better plan is to use the short dev cycle for 8.1 to
replace ARC and include any non-initdb changes and to branch an 8.2 now
if people with initdb changes don't want to wait to do further
development. This allows people to move away from arc using a proper
release with out having to do dump/reload; certainly the path of least
resistance for users. It is also cleaner for folks in non-patent
countries.
Of course this isn't something that has to be fixed in the next 4
months... if enough initdb level changes are close now, we could commit
to a 6 month initdb/arc replace dev cycle followed by a 3 month beta for
8.1 and release before the end of the year. That might be best anyway
since I think we probably have 3-4 major changes already waiting to go
that can certainly be finished within 6 months (2PC, autovacuum, Devrims
work, ARC replacement, potential pitr replication changes) which would
be plenty enough to warrant a new release. It's not as good as the
8.1/8.2 plan but better than the 8.0.x plan (IMHO).
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
Re: [HACKERS] Patent issues and 8.1
Bruce Momjian wrote: pgman wrote: ... What I would like to do is to pledge that we will put out an 8.0.X to address any patent conflict experienced by our users. This would include ARC or anything else. This way we don't focus just on ARC but have a plan for any patent issues that appear, and we don't have to adjust our development cycle until an actual threat appears. This "pledge" sounds like an open-ended commitment of an infinite number of development hours. I don't think you can pledge to address "any" patent conflict. There is a limit to the number of tgl-hours in a day :). One advantage we have is that we can easily adjust our code to work around patented code by just installing a new binary. (Patents that affect our storage format would be more difficult. A fix would have to perhaps rewrite the on-disk data.) "easily"? Maybe, maybe not. I don't think you can assume that the fix to as-yet-unknown patent conflicts is necessarily going to be easy. Even the USPTO occasionally grants patents on things that aren't trivial. Just my AUD0.02, which should probably be worth even less given the size of my contribution to postgresql to date. Tim -- --- Tim Allen [EMAIL PROTECTED] Proximity Pty Ltd http://www.proximity.com.au/ http://www4.tpg.com.au/users/rita_tim/ ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Patent issues and 8.1
Hello all, As I got the next digest of pg hackers, I see that Jean-Gerard Pailloncy has already advocated this idea. In no means I meant to copy :) as I am on the digest mode. However, I think it's a good path to go anyway as two people at least came up with it. Please do not disregard this idea. -s On Wed, 26 Jan 2005, Serguei A. Mokhov wrote: > Date: Wed, 26 Jan 2005 14:51:49 -0500 (EST) > From: Serguei A. Mokhov <[EMAIL PROTECTED]> > To: pgsql-hackers@postgresql.org > Subject: Re: Patent issues and 8.1 > > Hello all, > > With this "paten issue" on hand, can't we come up with a "pluggable" API > and pluggable cache-replacement modules so that folks who care not for US > patents can simply download and load in the "PgARC" module, and those who > can't, just load the "NeilLRU", or a "BetterThanARCCacheReplacement" > module that don't violate those pattents. If the modules all conform to > the same pg-cache-replacement API, they could be swapped on the fly. I > believe the API and the two modules: ARC of Jan and LRU of Neil, can be > implemented for 8.0.1 and be less invasive than just ARC yanked out and > replaced with LRU. > > I believe, PGDG does not need to concern itself with removing and all > traces of ARC from CVS or otherwise; on the conrary, it still can ship the > ARC module as an add-on to those who wish. This is possible because the > project is NOT hosted in the US (if I am wrong correct me). > > This idea will also help the commercial vendros of PG to write up their > own modules they think best, of if they can't, just always load in LRU in > their commerical deployments of PG in the US. > > -- Serguei A. Mokhov| /~\The ASCII Computer Science Department | \ / Ribbon Campaign Concordia University | XAgainst HTML Montreal, Quebec, Canada | / \ Email! ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Patent issues and 8.1
Hello all, With this "paten issue" on hand, can't we come up with a "pluggable" API and pluggable cache-replacement modules so that folks who care not for US patents can simply download and load in the "PgARC" module, and those who can't, just load the "NeilLRU", or a "BetterThanARCCacheReplacement" module that don't violate those pattents. If the modules all conform to the same pg-cache-replacement API, they could be swapped on the fly. I believe the API and the two modules: ARC of Jan and LRU of Neil, can be implemented for 8.0.1 and be less invasive than just ARC yanked out and replaced with LRU. I believe, PGDG does not need to concern itself with removing and all traces of ARC from CVS or otherwise; on the conrary, it still can ship the ARC module as an add-on to those who wish. This is possible because the project is NOT hosted in the US (if I am wrong correct me). This idea will also help the commercial vendros of PG to write up their own modules they think best, of if they can't, just always load in LRU in their commerical deployments of PG in the US. -- Serguei A. Mokhov| /~\The ASCII Computer Science Department | \ / Ribbon Campaign Concordia University | XAgainst HTML Montreal, Quebec, Canada | / \ Email! ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Patent issues and 8.1
On Wed, 26 Jan 2005, Hannu Krosing wrote: Ühel kenal päeval (teisipäev, 25. jaanuar 2005, 21:10-0400), kirjutas Marc G. Fournier: On Tue, 25 Jan 2005, Bruce Momjian wrote: So if we have to address it we call it 8.0.7 or something. My point is that we don't need to address it until we actually find out the patent is being enforced against someone, and that possibility is quite unlikely. Ah, so you are advocating waiting *until* the problem exists, even *after* we know a) there may be a problem and b) we know that we can fix it ... ? It may be my englisk skills, as I'm not a native speaker, but your temporal logic escapes me ... ... waiting *until* the problem exists ... there *may be* a problem ... so *bruce* advocates waiting *until* there *is* a problem, *we* know it *may be* (*there* ?) and we know we *can* fix the problem that *may be* ? Now you've totally confused me *shakes head* Bruce is advocating waiting until the Patent has been Granted, instead of doing something about it now, when we know the patent is going through the system (and will likely get granted) ... a "reactive" vs "proactive" response to the problem. Basically, after the patent is granted, we are going to scramble to get rid of the ARC stuff, instead of taking the time leadign up to the granting to get rid of it so that when granted, it isn't something we have to concern ourselves with ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Patent issues and 8.1
Neil Conway <[EMAIL PROTECTED]> writes: > Well, you've suggested that I should try and reduce the API churn caused > by the patch. As I said on -patches, I don't really see this as an issue > if we just apply the patch to REL8_0_STABLE. If we do that then the patch will go out with essentially no testing beyond your own; an idea that doesn't fill me with confidence. > I think the biggest area of concern with the LRU patch is how it changes > bgwriter behavior. The easiest way to handle that is to keep storing a full list of all the buffers in freelist.c, instead of reverting to the pre-8.0 data structure. (Of course, if we decide we *want* to change the bgwriter behavior, it's a different story.) > I think it would be better to have a few weeks of beta prior to 8.0.2 > and resolve the problem here and now, rather than crippling the 8.1 > cycle (as the no-initdb policy would) or waiting for the problem to > *really* become serious (as the "no action needed now" policy would). I'm leaning in that direction too, but I think that the only way to get any meaningful testing is to have the patch in HEAD as well as the back branch. So I want something that doesn't undo more than the minimum necessary to remove the ARC algorithm. I don't have time to deal with this today or tomorrow, but once the security releases are out, I will look at developing an LRU patch that fits with my ideas about how to do it. regards, tom lane ---(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] Patent issues and 8.1
Ühel kenal päeval (teisipäev, 25. jaanuar 2005, 21:10-0400), kirjutas Marc G. Fournier: > On Tue, 25 Jan 2005, Bruce Momjian wrote: > > So if we have to address it we call it 8.0.7 or something. My point is > > that we don't need to address it until we actually find out the patent > > is being enforced against someone, and that possibility is quite unlikely. > > Ah, so you are advocating waiting *until* the problem exists, even *after* > we know a) there may be a problem and b) we know that we can fix it ... ? It may be my englisk skills, as I'm not a native speaker, but your temporal logic escapes me ... ... waiting *until* the problem exists ... there *may be* a problem ... so *bruce* advocates waiting *until* there *is* a problem, *we* know it *may be* (*there* ?) and we know we *can* fix the problem that *may be* ? -- Hannu Krosing <[EMAIL PROTECTED]> ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Patent issues and 8.1
I live in Europe, and right now, the patent, if granted, would not have any effect on me. Even if Europe will have patents on software, I doubt that this ARC algorithm will be patentable in Europe. Is it possible to have an abstraction api where we can plug different algorithms. With two plugins : LRU, ARC. ARC in a contrib module on european server only. ;-) So any people get the best in regard to their local law. ;-/ It is a trick, a work-around, ok. BUT, a general way to have some plugins for cache, database file format, etc (like the one for new type/operator) could be very interesting : a) as a patent workaround b) as a framework to test new feature Cordialement, Jean-Gérard Pailloncy ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Patent issues and 8.1
Ühel kenal päeval (kolmapäev, 26. jaanuar 2005, 15:38+1100), kirjutas Neil Conway: > Bruce Momjian wrote: > > So if we have to address it we call it 8.0.7 or something. My point is > > that we don't need to address it until we actually find out the patent > > is being enforced against someone, and that possibility is quite unlikely. > > IMHO, the patent issue is *not* a "potential problem" for a lot of > people, it *is* a problem -- it makes people uncomfortable to be > deploying software that they know might cause them legal headaches down > the line. If people see we are scared by so little, I fear that someone will pop up another "potential patent problem" just after we have reverted to LRU. Or even better - a day or two before releasing 8.0.x withr RLU fix. > It also makes life difficult for people distributing > commercial versions of PostgreSQL. Simple repackaging should not be a basis of "commercial" version. If they want it, they could a) distribute OSS version and sell support b) test your LRU backpatch and sell (a likely worse performing) version with that. c) implement a better-than-ARC cache replacement scheme, and sell that. If they are really pissed off at PGDG they could even apply for a patent to that scheme and gain "competitive advantage" in their investors eyes. > I've posted a patch to -patches that replaces ARC with LRU. The patch is > stable -- I'll post some code cleanup for it tomorrow, but I've yet to > find any bugs despite a fair bit of testing. Have you done any performance comparisons with your LRU patch our 8.0 PgARC implementation. IIRC the differences between 7.4 and 8.0 were best visible on really heavy workloads, like the ones tested at OSDL. If the performance does not matter, the simplest solution would be setting postgres internal cache to 0 bytes and rely just on OS buffers. That stops infringement immediately as one is not *using* any patented technologies then. > I think the best solution is to replace ARC with LRU in 8.0.1 or 8.0.2, > and develop a better replacement policy during the 8.1 development cycle. That could be the best solution for those worried about it (commercial distributors mainly) but for the others a better tested and stable ARC- like solution we have implemented and tested now is probably still better. AN UNRELATED SUGGESTION: Could anybody take the patent application and comment it claim-by-claim marking up things having prior art (like claim 1 - keeping two lists), so that when we start designing our ARC replacement, we know what points we can safely "infringe" (IIRC some points involved doing LRU-like stuff, so if we decide to be unconditionally terrified by the patent application we should avoid LRU as well). Then we could put up the commented version on our website or perhaps havet it up at http://www.groklaw.net/ for comments from larger community already familiar with IP issues ;). Slashdot would be another place to ask for comments/prior art. My point is, that while the IBM's patent as a whole could be worth patent protection, each and every claim in it separately is probably not. -- Hannu Krosing <[EMAIL PROTECTED]> ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Patent issues and 8.1
Neil Conway wrote: IMHO, the patent issue is *not* a "potential problem" for a lot of people, it *is* a problem -- it makes people uncomfortable to be deploying software that they know might cause them legal headaches down the line. It also makes life difficult for people distributing commercial versions of PostgreSQL. I live in Europe, and right now, the patent, if granted, would not have any effect on me. Even if Europe will have patents on software, I doubt that this ARC algorithm will be patentable in Europe. I've posted a patch to -patches that replaces ARC with LRU. The patch is stable -- I'll post some code cleanup for it tomorrow, but I've yet to find any bugs despite a fair bit of testing. The patch also reverts the code to being quite close to 7.4, which is another reason to have some confidence in its correctness. I think the best solution is to replace ARC with LRU in 8.0.1 or 8.0.2, and develop a better replacement policy during the 8.1 development cycle. I have not much confidence in such changes in a minor release, seeing that there is really not much more testing on them than regression testing (am I wrong?) an perhaps simple benchmarking in this case. I believe many really annoying or dangerous bugs have only been found in field testing. Don't get me wrong, Neil, I trust your coding skills. But replacing ARC with LRU seems a rather big change, which could introduce new bugs and have performance issues. And the change also effects bgwriter behaviour. Please don't rush out untested core components, and perhaps think about the people who are quite comfortable with ARC (e.g. us guys in Europe over here). If ARC replacement can be done in a 8.0.* release, it doesn't have to be now in a rush, does it? Best Regards, Michael Paesold ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Patent issues and 8.1
Tom Lane wrote: I've already pointed out a couple reasons why I don't have any confidence in its correctness. Well, you've suggested that I should try and reduce the API churn caused by the patch. As I said on -patches, I don't really see this as an issue if we just apply the patch to REL8_0_STABLE. You never replied to my -patches mail -- AFAIK that's where the issue stands. I think the biggest area of concern with the LRU patch is how it changes bgwriter behavior. To review, the bgwriter currently does the following each time it is invoked: (1) acquire BufMgrLock (2) sweep through the entire buffer pool in LRU order, adding dirty pages to a list (3) examine a subset of the computed list according to bgwriter_maxpages and bgwriter_percent (4) for each element in the subset: (a) drop BufMgrLock (b) flush page to disk (c) reacquire BufMgrLock This is tricky to implement with LRU; we only record the recency of last access for unpinned pages, so we can't get the list in #2 (we can either get all dirty pages, as required for checkpoint, or all the unpinned dirty pages in LRU order). Besides which, the ARC behavior has some issues that were raised prior to the 8.0 release: scanning the whole buffer pool with the BufMgrLock held is bad. So the LRU patch changes the bgwriter to: (1) acquire the BufMgrLock (2) sweep through the free list (the list of unpinned buffers) in LRU order, adding up to bgwriter_maxpages dirty pages to the list 3) for each element in the list, write it out as in #4 above That means we don't hold the BufMgrLock for as long and the bgwriter doesn't consider flushing pinned pages (both a good idea IMHO), but it also means there's no consideration of bgwriter_percent. I'm not at all sure that this is the best compromise, however, so some comments would be welcome. Perhaps it would be best to keep bgwriter_percent, but redefine it to mean "the % of the buffer pool scanned by the bgwriter, at most." (I think this was Simon's idea originally.) This may be the right path to go for 8.0.* ... but we must NOT suppose that we can just push it out without a full beta test cycle. Yeah, I think a beta period would be a good idea (not nearly as long as the 8.0 beta period was, though). I think it would be better to have a few weeks of beta prior to 8.0.2 and resolve the problem here and now, rather than crippling the 8.1 cycle (as the no-initdb policy would) or waiting for the problem to *really* become serious (as the "no action needed now" policy would). -Neil ---(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] Patent issues and 8.1
Neil Conway <[EMAIL PROTECTED]> writes: > I've posted a patch to -patches that replaces ARC with LRU. The patch is > stable -- I'll post some code cleanup for it tomorrow, but I've yet to > find any bugs despite a fair bit of testing. The patch also reverts the > code to being quite close to 7.4, which is another reason to have some > confidence in its correctness. I've already pointed out a couple reasons why I don't have any confidence in its correctness. This may be the right path to go for 8.0.* ... but we must NOT suppose that we can just push it out without a full beta test cycle. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Patent issues and 8.1
Bruce Momjian wrote: So if we have to address it we call it 8.0.7 or something. My point is that we don't need to address it until we actually find out the patent is being enforced against someone, and that possibility is quite unlikely. IMHO, the patent issue is *not* a "potential problem" for a lot of people, it *is* a problem -- it makes people uncomfortable to be deploying software that they know might cause them legal headaches down the line. It also makes life difficult for people distributing commercial versions of PostgreSQL. I've posted a patch to -patches that replaces ARC with LRU. The patch is stable -- I'll post some code cleanup for it tomorrow, but I've yet to find any bugs despite a fair bit of testing. The patch also reverts the code to being quite close to 7.4, which is another reason to have some confidence in its correctness. I think the best solution is to replace ARC with LRU in 8.0.1 or 8.0.2, and develop a better replacement policy during the 8.1 development cycle. -Neil ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Patent issues and 8.1
On Tue, 25 Jan 2005, Bruce Momjian wrote: Marc G. Fournier wrote: One problem in working around the GIF format patent is that you had to create a file that was readable by many of the existing GIF readers. With PostgreSQL, only we read our own data files so we can more easily make adjustments to avoid patents. I did not see any reaction to my ideas above. Is this a good plan? No, as an 8.0.x is mean to be for minor changes/fixes/improvements ... 'addressing a patnt conflict', at least in ARC's case, is a major change, which is why we are looking at a short dev cycle for 8.1 ... So if we have to address it we call it 8.0.7 or something. My point is that we don't need to address it until we actually find out the patent is being enforced against someone, and that possibility is quite unlikely. Ah, so you are advocating waiting *until* the problem exists, even *after* we know a) there may be a problem and b) we know that we can fix it ... ? Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(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] Patent issues and 8.1
Marc G. Fournier wrote: > >> One problem in working around the GIF format patent is that you had to > >> create a file that was readable by many of the existing GIF readers. > >> With PostgreSQL, only we read our own data files so we can more easily > >> make adjustments to avoid patents. > > > > I did not see any reaction to my ideas above. Is this a good plan? > > No, as an 8.0.x is mean to be for minor changes/fixes/improvements ... > 'addressing a patnt conflict', at least in ARC's case, is a major change, > which is why we are looking at a short dev cycle for 8.1 ... So if we have to address it we call it 8.0.7 or something. My point is that we don't need to address it until we actually find out the patent is being enforced against someone, and that possibility is quite unlikely. By changing our development cycle just on the threat of a problem we are basically saying any patent holder can hinder PostgreSQL development by suggesting there is a patent problem but not actually doing anything that will give them bad press. The threat of bad press might be the only thing that is prevents us from being attacked by patents. -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Patent issues and 8.1
On Tue, 25 Jan 2005, Bruce Momjian wrote: pgman wrote: Not yet --- I suggested it but didn't get any yeas or nays. I don't feel this is solely core's decision anyway ... what do the assembled hackers think? I am not in favor of adjusting the 8.1 release based solely on this patent issue. I think the probability of the patent being accepted and enforced against anyone using PostgreSQL to be very unlikely. I would also like to come up with a procedure that would scale to any other patent problems we might have. What if someone finds another patent problem during 8.1 beta? Do we shorten the 8.2 development cycle too? What I would like to do is to pledge that we will put out an 8.0.X to address any patent conflict experienced by our users. This would include ARC or anything else. This way we don't focus just on ARC but have a plan for any patent issues that appear, and we don't have to adjust our development cycle until an actual threat appears. One advantage we have is that we can easily adjust our code to work around patented code by just installing a new binary. (Patents that affect our storage format would be more difficult. A fix would have to perhaps rewrite the on-disk data.) One problem in working around the GIF format patent is that you had to create a file that was readable by many of the existing GIF readers. With PostgreSQL, only we read our own data files so we can more easily make adjustments to avoid patents. I did not see any reaction to my ideas above. Is this a good plan? No, as an 8.0.x is mean to be for minor changes/fixes/improvements ... 'addressing a patnt conflict', at least in ARC's case, is a major change, which is why we are looking at a short dev cycle for 8.1 ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] Patent issues and 8.1
pgman wrote: > > Not yet --- I suggested it but didn't get any yeas or nays. I don't > > feel this is solely core's decision anyway ... what do the assembled > > hackers think? > > I am not in favor of adjusting the 8.1 release based solely on this > patent issue. I think the probability of the patent being accepted and > enforced against anyone using PostgreSQL to be very unlikely. I would > also like to come up with a procedure that would scale to any other > patent problems we might have. What if someone finds another patent > problem during 8.1 beta? Do we shorten the 8.2 development cycle too? > > What I would like to do is to pledge that we will put out an 8.0.X to > address any patent conflict experienced by our users. This would > include ARC or anything else. This way we don't focus just on ARC but > have a plan for any patent issues that appear, and we don't have to > adjust our development cycle until an actual threat appears. > > One advantage we have is that we can easily adjust our code to work > around patented code by just installing a new binary. (Patents that > affect our storage format would be more difficult. A fix would have to > perhaps rewrite the on-disk data.) > > One problem in working around the GIF format patent is that you had to > create a file that was readable by many of the existing GIF readers. > With PostgreSQL, only we read our own data files so we can more easily > make adjustments to avoid patents. I did not see any reaction to my ideas above. Is this a good plan? -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
