Re: Proposal: replace no-overwrite with Berkeley DB

The Hermit Hacker wrote:

On Mon, 15 May 2000, Peter Eisentraut wrote:

On Mon, 15 May 2000, The Hermit Hacker wrote:

Hrmmm, some sort of --with-berkeley-db configure switch, so by default, it
uses ours, but if someone wants to do the db code, it could plug-n-play?

But wasn't the main reason Michael Olson gave that a lot of code could be
removed because Berkeley DB does it for you? But with that switch we'd end
up with more code, not less.

right, and my point was that, up until now, we've worked at making sure
that the whole thing is self-contained ... as soon as we throw in a
third-party piece of software that is *efffectively* our guts, we now
throw in a new point of failure for the end users ... what happens if, a
year down the road, SleepyCat decides that v4.0 falls undera new license
that negates our ability to use it? we've just drop'd all our guts in
favor of theirs and now what?

There could be some ways to get a twisted license (like Medusa used in
Zope)
where the Berkeley DB used in PostgreSQL is free but used without
postgres
is still under the original Sleepycat terms.

That arrangement seems to work quite nicely with Zope.

I still don't see how we could replace some part of storage manager and
access methods guts with Berkeley DB and still keep the extended
features
like R-trees and MVCC (and sure there are others), and integrate two
types
of transaction management on top of them.

I'm not saying that using some of SleepyCat's stuff for backend is a bad
idea, but I'm saying that we shouldn't be relying on it ... add on, yes ...

But what would the idea of such add-on be ?

Does it offer real advantages over our current scheme ?
If so, is the integrating effort significantly less than fixing what we
have ?

BTW, is there a general-purpose optimisation library available that we
could use instead of our current one ? ;)

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

On Mon, 15 May 2000, Peter Eisentraut wrote:

On Mon, 15 May 2000, The Hermit Hacker wrote:

Hrmmm, some sort of --with-berkeley-db configure switch, so by default, it
uses ours, but if someone wants to do the db code, it could plug-n-play?

But wasn't the main reason Michael Olson gave that a lot of code could be
removed because Berkeley DB does it for you? But with that switch we'd end
up with more code, not less.

right, and my point was that, up until now, we've worked at making sure
that the whole thing is self-contained ... as soon as we throw in a
third-party piece of software that is *efffectively* our guts, we now
throw in a new point of failure for the end users ... what happens if, a
year down the road, SleepyCat decides that v4.0 falls undera new license
that negates our ability to use it? we've just drop'd all our guts in
favor of theirs and now what?

I'm not saying that using some of SleepyCat's stuff for backend is a bad
idea, but I'm saying that we shouldn't be relying on it ... add on, yes
... exclusive, no ...

right, and my point was that, up until now, we've worked at making sure
that the whole thing is self-contained ... as soon as we throw in a
third-party piece of software that is *efffectively* our guts, we now
throw in a new point of failure for the end users ... what happens if, a
year down the road, SleepyCat decides that v4.0 falls undera new license
that negates our ability to use it? we've just drop'd all our guts in
favor of theirs and now what?

I'm not saying that using some of SleepyCat's stuff for backend is a bad
idea, but I'm saying that we shouldn't be relying on it ... add on, yes
... exclusive, no ...

We could get perpetual rights to the code as integrated into our code.
Also, if they change something, we could always take it as our own and
keep it working for us. I think we would need something like that.

It sort of goes to how open we are. Someone can always take PostgreSQL
and create a branch if we do a terrible job. We would need that
assurance of the Sleepycat DB.

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

On Mon, 15 May 2000, Peter Eisentraut wrote:

On Mon, 15 May 2000, The Hermit Hacker wrote:

Everythingn up to here sounds great ... but this part here totally throws
me off ... this would mean that, unlike now where we rely on *zero*
external code,

... where `zero' is defined as regex package, GNU make, Autoconf, Flex,
Perl, multibyte code ...

where zero is defined as "I can build a binary, put it up on the ftp site,
and nobody has any other requirements in order to use it" ...

Effectively, if at some point down the road, the SleepyCat license
changes, the whole project just gets slam'd for a loop ...

Hmm, didn't you recently dismiss the argument "What if at some point down
the road PostgreSQL Inc./Great Bridge/Evil Empire changes the
license/abducts the source code of PostgreSQL" with "use the last free
version"?

Okay, then are we merging SleepyCat's code into ours, and distributing
their code? Or are we relying on someone having a copy of the libraries
already installed on their machine?

on 5/15/00 2:15 AM, Michael A. Olson at mao@sleepycat.com wrote:

Berkeley DB is Open Source. It's free for use in other Open Source
projects, like PostgreSQL. If a developer wants to use it in a
proprietary application, then the developer needs to pay Sleepycat
a licensing fee -- that's how we make our living. But Open Source
projects don't have to pay us anything. You can download the full
package from our Web site at www.sleepycat.com.

I have to add my 0.02 to this issue. I read the informal description of the
Sleepycat license (http://www.sleepycat.com/licensing.html). It looks like a
commercial twist on BSD with a GPL sense to it.

If this were a totally new product, I think it might be an acceptable
license, a compromise between BSD's total freedom and the GPL's push to keep
things open-source. However, given that there are existing users of Postgres
who probably use the binary without distributing source, this license is
significantly more restrictive than the previous one, and would force
current users to review their practices.

It seems that forcing this new license on Postgres would be
counter-productive at a time when the user base seems to be on the rise and
PostgreSQL is starting to make a new, quality name for itself in the
Open-Source community.

This is by no means a judgement of Berkeley DB Data Store as a product, just
a point about current users of PostgreSQL and their expectations.

Yes, it seems we would need some special arrangement from them. We
don't plan on changing our license just to use Sleepycat DB. In fact,
this is just an exploration. We don't even know if it will be a win for
us.

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

Benjamin Adida <ben@mit.edu> writes:

If this were a totally new product, I think it might be an acceptable
license, a compromise between BSD's total freedom and the GPL's push to keep
things open-source. However, given that there are existing users of Postgres
who probably use the binary without distributing source, this license is
significantly more restrictive than the previous one, and would force
current users to review their practices.

IMHO it would not be acceptable to make Postgres distribution even a
little less free than it is now. However, it could be that we can get
around that. According to the FAQ on Sleepycat's website, they consider
that the open-source restriction applies to the software that directly
calls Berkeley DB --- which would be Postgres. Code that sits atop
Postgres could still be proprietary without triggering licensing
requirements. So their existing policy is already close to what we'd
need.

Also, I note (forget if this is on their website or if it was in last
night's private email) that Sleepycat have cut some sort of special
licensing deal with Gnome to persuade the Gnome folks that it's OK for
them to depend on Berkeley DB. So I expect they'd be open to making
a similar deal with us. I think a written, signed agreement between
Sleepycat and us, guaranteeing that Berkeley DB + Postgres could be
distributed as freely as Postgres is now, is possible and would solve
everyone's concerns on this issue.

I'm more concerned about the technical issues, the biggest of which
is how we can preserve MVCC semantics. Mike made a good point that
users don't care about implementation technology --- but they do care
about results, and MVCC's lack of locking (readers don't block writers
nor vice versa) is an important result that I'm unwilling to give up.
I'm also dissatisfied with the idea of going through a "Recno" access
method to get at heap data; that sounds like a recipe for serious
performance degradation. However, maybe we could address issues like
that by working with the Sleepycat guys to develop a true heap access
method within their framework. The MVCC issue is more serious because
I'm not sure that could be added to their framework after-the-fact.

If we go into this at all, we'd certainly *not* want to take the
attitude that Berkeley DB is a closed box that we don't get to mess
with. It's open source and we'd be contributing improvements to it,
probably some pretty major ones. In effect we'd become partners with
the Sleepycat guys --- and so another big issue is how comfortable we
would be working together. But it could be a win-win proposition if
we join forces to produce better software than either group could do
alone.

I'm not at all sold that this is a workable proposal --- but I think
it has enough potential to be worth some close examination.

regards, tom lane

If we go into this at all, we'd certainly *not* want to take the
attitude that Berkeley DB is a closed box that we don't get to mess
with. It's open source and we'd be contributing improvements to it,
probably some pretty major ones. In effect we'd become partners with
the Sleepycat guys --- and so another big issue is how comfortable we
would be working together. But it could be a win-win proposition if
we join forces to produce better software than either group could do
alone.

Another option is to keep our heap table structure intact, and just
Sleepycat DB for our indexes. That may be a big win, with little
downside. Certainly something to think about. It may work better with
MVCC, and allow fast sequential scans and fast heap access from the
indexs, without having to go through the db structures to get to it.

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

Perhaps what you are talking about is at so low a level that it
has no influence on these features...but if not then it might be
that the writer of a WAL will want to write an implementation of
the storage manager that is well integrated with the WAL.

Yes, I would like to do this, if everyone agreed to wait for
7.2. Actually, I'm not sure if we're able to make both smgr
and WAL in 7.1

Vadim

Another option is to keep our heap table structure intact, and just
Sleepycat DB for our indexes. That may be a big win, with little
downside. Certainly something to think about. It may work
better with MVCC, and allow fast sequential scans and fast heap
access from the indexs, without having to go through the db structures
to get to it.

But... we will still have to implement new smgr for tables and
redo/undo functions for heap access method.

Vadim

We could get perpetual rights to the code as integrated into our code.
Also, if they change something, we could always take it as our own and
keep it working for us. I think we would need something like that.

One of the often-stated virtues of PGSQL is that it is easy for a company
to take the source and go commercial. If you start integrating 'special
license greements' into the development, then that advantage is severly
reduced.

A commercial operator has to form an agreement with sleepycat or rewrite
the storage manager. Unless sleepycat grant a completely open license to
PGSQL and all it's commercial descendants in perpetuity, it seems you may
be removing one of the seeling points of PGSQL.

----------------------------------------------------------------
Philip Warner | __---_____
Albatross Consulting Pty. Ltd. |----/ - \
(A.C.N. 008 659 498) | /(@) ______---_
Tel: +61-03-5367 7422 | _________ \
Fax: +61-03-5367 7430 | ___________ |
Http://www.rhyme.com.au | / \|
| --________--
PGP key available upon request, | /
and from pgp5.ai.mit.edu:11371 |/

We could get perpetual rights to the code as integrated into our code.
Also, if they change something, we could always take it as our own and
keep it working for us. I think we would need something like that.

One of the often-stated virtues of PGSQL is that it is easy for a company
to take the source and go commercial. If you start integrating 'special
license greements' into the development, then that advantage is severly
reduced.

A commercial operator has to form an agreement with sleepycat or rewrite
the storage manager. Unless sleepycat grant a completely open license to
PGSQL and all it's commercial descendants in perpetuity, it seems you may
be removing one of the seeling points of PGSQL.

Yes, something like this would be required.

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

Several people have asked about the terms of the Berkeley DB license,
and the conditions under which users need to pay Sleepycat for
redistribution.

To clarify, you're permitted to redistribute binary copies of your
application, including Berkeley DB, as long as source code is freely
available *somewhere*. Anyone could compile and sell PostgreSQL on
a CD without paying Sleepycat, because the source code remains
available on PostgreSQL.org.

Lots of people ship binary copies of the OpenLDAP directory server,
which uses Berkeley DB. They don't pay us. Only the companies that
ship proprietary directory servers do.

License fees are only required if you make a proprietary version of
the Open Source product. For example, if a vendor took PostgreSQL,
made changes to the backend, and didn't contribute those changes
back to PostgreSQL.org, then the vendor would have to pay Sleepycat
for the right to redistribute our software as a part of the package.

For the purposes of this proposal, we'd consider the PostgreSQL
backend to be the embedding app -- that is, anyone could develop
new proprietary clients, since those don't directly embed our code.
And we stipulate that dynamically-loaded functions that implement
user-defined types and functions don't constitute changes to the
backend.

So the only case in which a license fee would be required would
be if someone forked the backend and kept their changes proprietary.
I'm not aware of anyone distributing a forked version of the
backend now, but I've been outside the community for a while now.

I understand the implications of the BSD and GPL licenses, and why
they're appropriate or inappropriate for particular cases. If the
Berkeley DB license imposes conditions on PostgreSQL that aren't
in keeping with the desires of the developers, then of course the
proposed project won't work.

If you've got additional questions on the license, ask away.

mike

Several people have asked about the terms of the Berkeley DB license,
and the conditions under which users need to pay Sleepycat for
redistribution.

To clarify, you're permitted to redistribute binary copies of your
application, including Berkeley DB, as long as source code is freely
available *somewhere*. Anyone could compile and sell PostgreSQL on
a CD without paying Sleepycat, because the source code remains
available on PostgreSQL.org.

Lots of people ship binary copies of the OpenLDAP directory server,
which uses Berkeley DB. They don't pay us. Only the companies that
ship proprietary directory servers do.

License fees are only required if you make a proprietary version of
the Open Source product. For example, if a vendor took PostgreSQL,
made changes to the backend, and didn't contribute those changes
back to PostgreSQL.org, then the vendor would have to pay Sleepycat
for the right to redistribute our software as a part of the package.

Seems this changes our license more toward GPL. I don't think that is
going to be supportable by the group. I doubt we are willing to modify
our license in order to use the Sleepycat DB code.

We don't use GPL code in PostgreSQL for the same reason.

I understand the implications of the BSD and GPL licenses, and why
they're appropriate or inappropriate for particular cases. If the
Berkeley DB license imposes conditions on PostgreSQL that aren't
in keeping with the desires of the developers, then of course the
proposed project won't work.

Sorry, looks like a deal killer. Of course, others will voice their
opinions. This is just my guess.

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

At 11:08 AM 5/16/00 +1000, you wrote:

Essentially, this is the same as the GPL licence, right?

Yes, except that companies that want to distribute proprietary versions
can pay for the privilege.

mike

At 09:15 PM 5/15/00 -0400, you wrote:

Sorry, looks like a deal killer. Of course, others will voice their
opinions. This is just my guess.

Given the preferences that I've heard expressed so far, I think you're
probably right. And it sounds as if Vadim's making progress on a WAL
that will preserve multi-versioning, so that's another reason for you
to stick with what you've got now.

Never hurts to ask, though :-). If the situation changes at some
point, and you'd like to resume the discussion, we'd be glad to do
that.
mike

Perhaps what you are talking about is at so low a level that it
has no influence on these features...but if not then it might be
that the writer of a WAL will want to write an implementation of
the storage manager that is well integrated with the WAL.

Yes, I would like to do this, if everyone agreed to wait for
7.2. Actually, I'm not sure if we're able to make both smgr
and WAL in 7.1

istm that future work on distributed databases would require some
generic API layer, perhaps identical to the current smgr layer or
perhaps something higher up. Maybe an alternate local storage scheme
could plug into that same interface, much as storage managers used to
do.

If this is accurate, then someone could demonstrate the sleepycat code
without having to impact other parts of the code?

- Thomas

--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California

On Mon, 15 May 2000, Bruce Momjian wrote:

Several people have asked about the terms of the Berkeley DB license,
and the conditions under which users need to pay Sleepycat for
redistribution.

To clarify, you're permitted to redistribute binary copies of your
application, including Berkeley DB, as long as source code is freely
available *somewhere*. Anyone could compile and sell PostgreSQL on
a CD without paying Sleepycat, because the source code remains
available on PostgreSQL.org.

Lots of people ship binary copies of the OpenLDAP directory server,
which uses Berkeley DB. They don't pay us. Only the companies that
ship proprietary directory servers do.

License fees are only required if you make a proprietary version of
the Open Source product. For example, if a vendor took PostgreSQL,
made changes to the backend, and didn't contribute those changes
back to PostgreSQL.org, then the vendor would have to pay Sleepycat
for the right to redistribute our software as a part of the package.

Seems this changes our license more toward GPL. I don't think that is
going to be supportable by the group. I doubt we are willing to modify
our license in order to use the Sleepycat DB code.

I don't know ... I read this as totally anti-GPL ... "you are more then
welcome to distribute binary only, but then you have to pay us for use of
our libraries" ...

... the only aspect that would worry me is if SleepCat were to change
their license and make it more restrictive ...

Seems this changes our license more toward GPL. I don't think that is
going to be supportable by the group. I doubt we are willing to modify
our license in order to use the Sleepycat DB code.

I don't know ... I read this as totally anti-GPL ... "you are more then
welcome to distribute binary only, but then you have to pay us for use of
our libraries" ...

... the only aspect that would worry me is if SleepCat were to change
their license and make it more restrictive ...

But it ties the hands of binary-only distributors, or pay them. Not a
good choice.

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

On Mon, 15 May 2000, Bruce Momjian wrote:

Seems this changes our license more toward GPL. I don't think that is
going to be supportable by the group. I doubt we are willing to modify
our license in order to use the Sleepycat DB code.

I don't know ... I read this as totally anti-GPL ... "you are more then
welcome to distribute binary only, but then you have to pay us for use of
our libraries" ...

... the only aspect that would worry me is if SleepCat were to change
their license and make it more restrictive ...

But it ties the hands of binary-only distributors, or pay them. Not a
good choice.

Woah here ... didn't Michael state that binary-only was okay, as long as
the source *was* available on the 'Net? ie. Enhydra can distribute their
binaries, as long as sources were still available on postgresql.org?

At 11:52 AM 5/16/00 +1000, Chris Bitmead wrote:

That's no different to GPL. One is always free to negotiate with the
author a fee to not have to abide the standard licence. Out of
curiousity, any reason you didn't just use the GPL as-is since it is the
same idea?

Berkeley DB already carried the University of California copyright,
and we couldn't remove it or the conditions it imposed. We'd have
preferred the GPL but we'd have had to craft a more complicated and
newer license the preserved the UC terms and the GNU terms.

mike

Thomas Lockhart <lockhart@alumni.caltech.edu> writes:

istm that future work on distributed databases would require some
generic API layer, perhaps identical to the current smgr layer or
perhaps something higher up. Maybe an alternate local storage scheme
could plug into that same interface, much as storage managers used to
do.
If this is accurate, then someone could demonstrate the sleepycat code
without having to impact other parts of the code?

As far as I can tell, the current smgr switch is at a much lower level
than the Berkeley DB API is --- smgr's API involves reading and writing
disk blocks, and the contents of those blocks is the concern of higher
levels like bufmgr and the various access methods. BDB would want to
replace most of the access-method layer, not to mention bufmgr, lockmgr,
a lot of the shmem code, and maybe parts of transam. We don't have a
single API that covers that territory, and I'm not sure it'd be
reasonable to try to make one.

Another problem is that we've been kinda sloppy about preserving purity
of the APIs that we have --- for example, relation rename ought to be
done via an smgr call, but instead it's been hacked into higher-level
code. Cleaning up that sort of thing would be a good idea in any case,
but it's just part of the work you'd have to do before you could think
about plugging in BDB.

regards, tom lane

On Mon, 15 May 2000, Bruce Momjian wrote:

Seems this changes our license more toward GPL. I don't think that is
going to be supportable by the group. I doubt we are willing to modify
our license in order to use the Sleepycat DB code.

I don't know ... I read this as totally anti-GPL ... "you are more then
welcome to distribute binary only, but then you have to pay us for use of
our libraries" ...

... the only aspect that would worry me is if SleepCat were to change
their license and make it more restrictive ...

But it ties the hands of binary-only distributors, or pay them. Not a
good choice.

Woah here ... didn't Michael state that binary-only was okay, as long as
the source *was* available on the 'Net? ie. Enhydra can distribute their
binaries, as long as sources were still available on postgresql.org?

But that limits companies from distributing binary-only versions where
they don't want to give out the source.

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

Bruce Momjian <pgman@candle.pha.pa.us> writes:

Woah here ... didn't Michael state that binary-only was okay, as long as
the source *was* available on the 'Net? ie. Enhydra can distribute their
binaries, as long as sources were still available on postgresql.org?

But that limits companies from distributing binary-only versions where
they don't want to give out the source.

The way I read it was that as long as *we* are making Postgres source
available, people using Postgres as a component wouldn't have to, nor
make their own source available which'd probably be the real issue.

OTOH, there'd still be a problem with distributing slightly-modified
versions of Postgres --- that might require a Sleepycat license.

On the whole this seems like a can of worms better left unopened.
We don't want to create questions about whether Postgres is free
or not.

regards, tom lane

Bruce Momjian <pgman@candle.pha.pa.us> writes:

Woah here ... didn't Michael state that binary-only was okay, as long as
the source *was* available on the 'Net? ie. Enhydra can distribute their
binaries, as long as sources were still available on postgresql.org?

But that limits companies from distributing binary-only versions where
they don't want to give out the source.

The way I read it was that as long as *we* are making Postgres source
available, people using Postgres as a component wouldn't have to, nor
make their own source available which'd probably be the real issue.

OTOH, there'd still be a problem with distributing slightly-modified
versions of Postgres --- that might require a Sleepycat license.

On the whole this seems like a can of worms better left unopened.
We don't want to create questions about whether Postgres is free
or not.

Agreed.

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

On Mon, May 15, 2000 at 09:53:34AM -0300, The Hermit Hacker wrote:

On Mon, 15 May 2000, Hannu Krosing wrote:

Everythingn up to here sounds great ... but this part here totally throws
me off ... this would mean that, unlike now where we rely on *zero*
external code, we essentially gut our internals and create API-links to
someone else's code ...

And what will happen to R-trees and Gist access methods ?

Will we implement them on top of Berkeley DB :) ?

OTOH, it may be good to have a clearly defined API to our own storage
manager that could possibly be used separately from the rest of PostgreSQL.

So people who can't accept/afford BSDDB licence could use ours instead.

Hrmmm, some sort of --with-berkeley-db configure switch, so by default, it
uses ours, but if someone wants to do the db code, it could plug-n-play?

That one has possibilities ...

I have not looked at what kind of API would be required, but this
would be my favorite. It sould be nice to be able to choose different
storage methods, optimized for different data patterns or even for
different media.

--
Adam Haberlach |"You have to understand that the
adam@newsnipple.com | entire 'Net is based on people with
http://www.newsnipple.com/ | too much free time on their hands."

Seems like something went wrong with the new Majordomo. I used to get ~50-60
messages per day from pgsql-hackers and interfaces lists. Now I get 1-2 per
day. It started last week. Apparently something is wrong with the majordomo
setup.

Gene Sokolov.

PRS ... PostReleaseSyndrome ... ppl are rebuilding up their energy,
watching for bugs while waiting for development to start up again.

On Tue, 16 May 2000, Gene Sokolov wrote:

Seems like something went wrong with the new Majordomo. I used to get ~50-60
messages per day from pgsql-hackers and interfaces lists. Now I get 1-2 per
day. It started last week. Apparently something is wrong with the majordomo
setup.

Gene Sokolov.

Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

The Hermit Hacker <scrappy@hub.org> writes:

PRS ... PostReleaseSyndrome ... ppl are rebuilding up their energy,
watching for bugs while waiting for development to start up again.

If he's only getting one or two messages a day, then something's surely
broken! According to my maillog there were 92 messages on the pghackers
list yesterday, and another 20+ on interfaces.

However, I'm inclined to think that the breakage is on his end, since
no one else is complaining ...

BTW, did I mention that I confirmed majordomo had lost my subscription
to pgsql-patches? I did a who on the list and found no entry. Curious.
Doesn't seem to have happened on any other list, but it explains why
I've seen no patches for a good while.

regards, tom lane

On Tue, 16 May 2000, Tom Lane wrote:

The Hermit Hacker <scrappy@hub.org> writes:

PRS ... PostReleaseSyndrome ... ppl are rebuilding up their energy,
watching for bugs while waiting for development to start up again.

If he's only getting one or two messages a day, then something's surely
broken! According to my maillog there were 92 messages on the pghackers
list yesterday, and another 20+ on interfaces.

However, I'm inclined to think that the breakage is on his end, since
no one else is complaining ...

Regardless of which end is at fault, I am looking at this from our end
anyway ... I'm wondering if maybe there was a connection problem to his
system and the mail system itself just bounced it ...

BTW, did I mention that I confirmed majordomo had lost my subscription
to pgsql-patches? I did a who on the list and found no entry.
Curious. Doesn't seem to have happened on any other list, but it
explains why I've seen no patches for a good while.

I'm embarressed to say that the Mj2 guys took a look at our system logs
and, ummmm, it doesn't look like some ppl were subscribed to the
pgsql-patches list when we first moved it over :( Looks like definitely
operator error on this one *sigh*

From: "The Hermit Hacker" <scrappy@hub.org>

On Tue, 16 May 2000, Tom Lane wrote:

The Hermit Hacker <scrappy@hub.org> writes:

PRS ... PostReleaseSyndrome ... ppl are rebuilding up their energy,
watching for bugs while waiting for development to start up again.

If he's only getting one or two messages a day, then something's surely
broken! According to my maillog there were 92 messages on the pghackers
list yesterday, and another 20+ on interfaces.

However, I'm inclined to think that the breakage is on his end, since
no one else is complaining ...

Regardless of which end is at fault, I am looking at this from our end
anyway ... I'm wondering if maybe there was a connection problem to his
system and the mail system itself just bounced it ...

Thanks for helping me. Unfortunately your subscription reset did not help.
The traffic is still the same. I don't believe the problem is on my end
becuase the traffic I get from the freebsd-stable as well as a couple of
other lists is usual. I also get a large traffic from customers, which is
not affected in any way. Just the two postgres lists are affected.

I vaguely remember getting a couple of test messages from one of the pg
lists about ten days ago and I think the volume dropped right after that.

We did have a connectivity outage some time ago when both our primary
and seconday MXs were unavailable, but it did not last longer than a couple
of hours. If Majordomo unsubscribed me, I wonder why I still get any traffic
from pg and why the subscription reset did not help.

Gene Sokolov.

On Wed, 17 May 2000, Gene Sokolov wrote:

From: "The Hermit Hacker" <scrappy@hub.org>

On Tue, 16 May 2000, Tom Lane wrote:

The Hermit Hacker <scrappy@hub.org> writes:

PRS ... PostReleaseSyndrome ... ppl are rebuilding up their energy,
watching for bugs while waiting for development to start up again.

If he's only getting one or two messages a day, then something's surely
broken! According to my maillog there were 92 messages on the pghackers
list yesterday, and another 20+ on interfaces.

However, I'm inclined to think that the breakage is on his end, since
no one else is complaining ...

Regardless of which end is at fault, I am looking at this from our end
anyway ... I'm wondering if maybe there was a connection problem to his
system and the mail system itself just bounced it ...

Thanks for helping me. Unfortunately your subscription reset did not help.
The traffic is still the same. I don't believe the problem is on my end
becuase the traffic I get from the freebsd-stable as well as a couple of
other lists is usual. I also get a large traffic from customers, which is
not affected in any way. Just the two postgres lists are affected.

I vaguely remember getting a couple of test messages from one of the pg
lists about ten days ago and I think the volume dropped right after that.

We did have a connectivity outage some time ago when both our primary
and seconday MXs were unavailable, but it did not last longer than a couple
of hours. If Majordomo unsubscribed me, I wonder why I still get any traffic
from pg and why the subscription reset did not help.

Are you running any kind of filtering software? Procmail or perhaps
something built into OE? Maybe there's a header that you're keying off
of that's dumping the mail to the trash. Around the time of the test
messages was the mail2news gateway stuff, I don't know if there were any
more headers put in tho. (haven't paid attention)

Vince.
--
==========================================================================
Vince Vielhaber -- KA8CSH email: vev@michvhf.com http://www.pop4.net
128K ISDN from $22.00/mo - 56K Dialup from $16.00/mo at Pop4 Networking
Online Campground Directory http://www.camping-usa.com
Online Giftshop Superstore http://www.cloudninegifts.com
==========================================================================

From: "Vince Vielhaber" <vev@michvhf.com>

Are you running any kind of filtering software? Procmail or perhaps
something built into OE? Maybe there's a header that you're keying off
of that's dumping the mail to the trash. Around the time of the test
messages was the mail2news gateway stuff, I don't know if there were any
more headers put in tho. (haven't paid attention)

No, I don't have any filters. But even if the mail was dumped to the trash,
I should have seen it there.

I just checked maillog on our primary MX (sendmail 8.9.3). Grepping for
hub.org and postgresql.org produced just 2 entries. Grepping the same log
for freebsd.org produced a few dozen entries which is about the right number
for the traffic there. This evidently rules out any settings local to my
workstation. I tend to believe that majordomo is not even trying to deliver
anything to me.

Is it possible that majordomo2 can automatically consider some domains
"bad" and not deliver? Something like compiling a list of domains where it
once failed to deliver mail?

Gene Sokolov.

The Hermit Hacker <scrappy@hub.org> writes:

I don't know ... I read this as totally anti-GPL ... "you are more then
welcome to distribute binary only, but then you have to pay us for use of
our libraries" ...

GPL (as opposed to LGPL) has been used for that purpose - either GPL
your code, or if you want to keep it proprietary: Pay us, and we'll
give you the same code with a different license.

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