Re: [GENERAL] 7.0 vs. 7.1 (was: latest version?)

[ Charset ISO-8859-1 unsupported, converting... ]
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
>
> > Let them. It is their decision. Frankly, I have seen this attitude
> > before, and I don't like it. Just the mention that "Gee, if you don't
> > cooperate, we may yank you," is really a veiled threat. Now, I know you
> > aren't saying that, but the "if you don't play nice, we will drop you"
> > argument sounds a lot more like MS that a Linux vendor should be acting,
> > especially since they are not telling us what they want or assisting in
> > the work.
>
> FWIW, I've never threatened to do so. If I wanted to, I would just do
> it[1] - threats are bad and never cause anything but bad feelings.

Sounds good.

>
> That being said, my favorite wishes (in addition to as much SQL
> compliance and performance as possible, of course) are:

OK, here is a nice list I can address constructively:

>
> * migration on upgrade

Yes, we have problems. 7.1 will have a more robust pg_dump, and I hope
that fixes most of those problems. As you see issues here, we need to
hear about it.

> * old libraries being able to speak to newer databases, so old
> binaries can continue working after database upgrades

We have always been able to do that. Old clients can talk to newer
databases, though new can't necessary talk to older. To the extent that
the client assumes a particular database structure, we have problems
there, especially psql. I most cases, those match the server, so I
think we are OK here, and most 3-rd party stuff doesn't touch the system
tables in areas that are changed frequently.

> * good sonames on libraries - if a library hasn't changed, bumping the
> number to show it's part of a new version isn't necesarry. If it is
> backwards compatible, just bump the minor version, if it isn't, bump
> the major version. Or even better, use versioned symbols (I don't
> know how many other OSes than Linux and Solaris supports this,
> though).

We only bump minor .so numbers, except for 6.5 I think where we had a
major overhaul of libpq and the major was bumped. I don't see another
major bump on the horizon. I don't think we have ever shipped a server
that could not talk to clients at least one major revison backwards.

The big question is how RPM's handle that. I have no idea.

> As for assisting, at least Red Hat contributes to a lot of projects,
> some of which are important to postgres on one or more platforms: gdb,
> gcc, glibc and the linux kernel. There just isn't enough resources to
> do everything, but I try to help out with the RPMs.

We only need help to the extent RPM people are asking for major feature
additions that affect only RPM/Linux, and frankly, the RPM/Linux users
should be supplying patches to us for that anyway. No need for the
company to get involved.

> When we make patches for packages, we try to cooperate with the
> author(s) to get them in - happily, we haven't had much of a need for
> that with postgresql.

Yes, I have never seen one.

> > The "We are big. Just fix it and let us know when it is ready" attitude
> > does not work here, and that is what I am hearing mostly from the RPM
> > people.
>
> I haven't heard anyone say that.

Some of the RPM users have made some demands that sound a little like
that. :-)

> > There must be a list of known problems. Let's hear them, so we can try
> > to solve them as a group. However, in general, we do not make dramatic
> > change to work around OS bugs, and do not plan to make major changes to
> > work around the limitations of RPM's.
>
> I don't think there are any apart from the upgrade issues - if library
> versioning follows the standard, that certainly won't be a problem.

I would love to get a detailed list of upgrade problems so we can be
sure 7.1 has them fixed. Certainly 7.1 is already a big improvement for
upgrades.

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