Or else people in our situation where it takes forever to upgrade the software because of its heavy use and the risk involved in upgrading, not to mention the problems encountered when we did test-runs of the upgrade.
Then there is always the thorny issue of loads of software that uses the databases, most of it under user control and any incompatibility between versions, no matter how small, could have horrible implications for our clients and therefore, us. You see, we are an ISP and a consultancy specialising in database-driven web sites and corporate infrastructure. We based nearly everything that we do on PostgreSQL and although we upgrade when we can, our hands are very tied. For us, patching is a necessity, not an option. To migrate a client means rebuilding an entire UAT (user acceptance test site) for them, extensively testing what we can ourselves, then asking the client to allocate time, money and people to test their systems and their own code as well. They will also need to allocate development time, money and people to fix any problems that they find in compatibility. Then there is the throny issue of both companies needing to synchronise their resources and schedules so that we can work together solving any problems that arise. Finally, because we have no control over the customer's quality control, and because customers very often don't have the inhouse expertise to even understand what a proper test is about (they most often have hired in expensive consultants or contracted other companies to do the work), we have no guarantees that when the client thinks that they have tested the site, they really have. Now most people will say "that's their problem", but you see, it isn't. Because these are business-critical systems that we're talking about and the change was initiated by us. So if the system fails, for whatever reason, on the new software, even if it isn't anything to do with the new software, we get the flack. And also in the clients' eyes, we are responsible because their system "was working fine until [we] forced and upgrade to new software". And that is customer relations being damanged, even if the customer is wrong. See the problem? I am only writing this to add to the pool of knowledge about how PG is used and the real-world implications of PG being used for business critical or customer-image systems. PG is extremely well suited for this and the benefits over closed-source systems is enormous, not to mention the fact that PG has email lists like this one with all the fine brains on this list pooled together. It shows in the code and it shows in the satisfaction level of those who use it (I have never once had a client who was dissatisfied with PG. Most clients were surprised that OpenSource existed, that it is free and that it is such great quality without any catches or got-yous that normally comes with "free" things from commercial companies.). Well, that's my hat in the ring. Hope that it helps someone out there or at least adds something to our pooled knowledge! Brad Kieser.net >>>>>>>>>>>>>>>>>> Original Message <<<<<<<<<<<<<<<<<< On 5/3/02, 4:43:31 AM, Lincoln Yeoh <[EMAIL PROTECTED]> wrote regarding Re: [HACKERS] a vulnerability in PostgreSQL : > I hope you won't make this standard practice. Because there are quite > significant differences that make upgrading from 7.1.x to 7.2 troublesome. > I can't name them offhand but they've appeared on the list from time to time. > For 6.5.x to 7.1.x I believe there are smaller differences, even so there > might be people who would patch for security/bug issues but not upgrade. > I'm still on Windows 95 for instance (Microsoft has stopped supporting it > tho :( ). I think there are still lots of people on Oracle 7. > Yes support of older software is a pain. But the silver lining is: it's > open source they can feasibly patch it themselves if they are really hard > pressed. If the bug report is descriptive enough DIY might not be so bad. > And just think of it as people really liking your work :). > Any idea which versions of Postgresql have been bundled with O/S CDs? > Regards, > Link. > At 10:23 AM 5/2/02 -0400, Tom Lane wrote: > >Tatsuo Ishii <[EMAIL PROTECTED]> writes: > > > Here are the precise conditions to trigger the scenario: > > > > > (1) the backend is PostgreSQL 6.5.x > > > (2) multibyte support is enabled (--enable-multibyte) > > > (3) the database encoding is SQL_ASCII (other encodings are not > > > affected by the bug). > > > (4) the client encoding is set to other than SQL_ASCII > > > > > I think I am responsible for this since I originally wrote the > > > code. Sorry for this. I'm going to make back port patches to fix the > > > problem for pre 7.2 versions. > > > >It doesn't really seem worth the trouble to make patches for 6.5.x. > >If someone hasn't upgraded yet, they aren't likely to install patches > >either. (ISTR there are other known security risks in 6.5, anyway.) > >If the problem is fixed in 7.0 and later, why not just tell people to > >upgrade? > > > > regards, tom lane > > > >---------------------------(end of broadcast)--------------------------- > >TIP 4: Don't 'kill -9' the postmaster > ---------------------------(end of broadcast)--------------------------- > TIP 2: you can get off all lists at once with the unregister command > (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED]) ---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
