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: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664

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

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: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664

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

Neil Conway <neilc@samurai.com> 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

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

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

Ü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 <hannu@tm.ee>

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

Ü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 <hannu@tm.ee>

Neil Conway <neilc@samurai.com> 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

This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.

--0-918242224-1106762583=:81692
Content-Type: TEXT/PLAIN; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: QUOTED-PRINTABLE

On Wed, 26 Jan 2005, Hannu Krosing wrote:

=DChel kenal p=E4eval (teisip=E4ev, 25. jaanuar 2005, 21:10-0400), kirjut=

as

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 unlike=

ly.

Ah, so you are advocating waiting *until* the problem exists, even *afte=

r*

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=
=20
doing something about it now, when we know the patent is going through the=
=20
system (and will likely get granted) ... a "reactive" vs "proactive"=20
response to the problem.

Basically, after the patent is granted, we are going to scramble to get=20
rid of the ARC stuff, instead of taking the time leadign up to the=20
granting to get rid of it so that when granted, it isn't something we have=
=20
to concern ourselves with ...

----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
--0-918242224-1106762583=:81692--

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 | X Against HTML
Montreal, Quebec, Canada | / \ Email!

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 <mokhov@cs.concordia.ca>
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 | X Against HTML
Montreal, Quebec, Canada | / \ Email!

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 tim@proximity.com.au
Proximity Pty Ltd http://www.proximity.com.au/
http://www4.tpg.com.au/users/rita_tim/

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

Robert Treat <xzilla@users.sourceforge.net> 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

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: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664

"Marc G. Fournier" <scrappy@postgresql.org> 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

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

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 Berkus Consultant
josh@agliodbs.com www.agliodbs.com
Ph: 415-752-2500 Fax: 415-752-2387
2166 Hayes Suite 200 San Francisco, CA

Josh Berkus <josh@agliodbs.com> 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

On Thursday 27 January 2005 10:27, Tom Lane wrote:

Robert Treat <xzilla@users.sourceforge.net> 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

Robert Treat <xzilla@users.sourceforge.net> 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

On Thursday 27 January 2005 20:47, Tom Lane wrote:

Robert Treat <xzilla@users.sourceforge.net> 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

On Thu, 27 Jan 2005, Robert Treat wrote:

On Thursday 27 January 2005 20:47, Tom Lane wrote:

Robert Treat <xzilla@users.sourceforge.net> 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: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664

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

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

-----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 greg@turnstep.com
PGP Key: 0x14964AC8 200501282155
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8

-----BEGIN PGP SIGNATURE-----

iD8DBQFB+vtuvJuQZxSWSsgRAnB8AKDnUsQM7xb1tRF93ehT05xg6Bf6TwCeOYn9
JdP4di03yzuSB9aaVskXb5g=
=U9HF
-----END PGP SIGNATURE-----

"Greg Sabino Mullane" <greg@turnstep.com> 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

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

Robert Treat <xzilla@users.sourceforge.net> 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

On Saturday 29 January 2005 11:33, Tom Lane wrote:

Robert Treat <xzilla@users.sourceforge.net> 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

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

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

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

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

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: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664

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: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664

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

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. "

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: scrappy@hub.org 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. #
#================================================== JanWieck@Yahoo.com #

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

Andrew Dunstan <andrew@dunslane.net> 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

At 2005-02-07 12:28:34 -0500, tgl@sss.pgh.pa.us 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