Re: [HACKERS] Can we revisit the thought of PostgreSQL 7.2.4?
This is an interesting thought. My gut tells me it is a viable opportunity for the corporate entities that offer support and wish to have 'VAR' status. This is just my opinion, but I view the core development group as pure development, and the various people that resell or distribute PostgreSQL as a for-profit business as those responsible for maintaining backward support. Maybe RedHat or PostgreSQL Inc can do this? It is a really good message, The best of open source, with on going support. And not to re-open a can of worms, but if PostgreSQL could upgrade without having to do a dump and restore, then this wouldn't really be an issue. Justin Clift wrote: Hi everyone, Over the last few days we've had patches submitted for 7.2.3 that address a couple of things, both the WAL Recovery Bug that Tom has developed a patch for, and a couple of buffer overflows that have been widely reported. Although we haven't wanted to release a 7.2.4, and have instead encouraged people to upgrade to 7.3.x, there are places out there who's applications aren't compatible with 7.3.x and would also need to upgrade them as well. It might be a really good idea if we re-visit the thought of 7.2.4 and have something that people running the 7.2.x series can use safely until they are able to move to 7.3.x or above. What would it take, and apart from patches for the buffer overflows and the WAL recovery bug, should anything else be included to ensure safety and stability? :-) Regards and best wishes, Justin Clift ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Can we revisit the thought of PostgreSQL 7.2.4?
mlw wrote: This is an interesting thought. My gut tells me it is a viable opportunity for the corporate entities that offer support and wish to have 'VAR' status. This is just my opinion, but I view the core development group as pure development, and the various people that resell or distribute PostgreSQL as a for-profit business as those responsible for maintaining backward support. Maybe RedHat or PostgreSQL Inc can do this? It is a really good message, The best of open source, with on going support. Very interesting thought. It could probably be done. Oh, hang on... Red Hat is taking that angle for now. :-) And not to re-open a can of worms, but if PostgreSQL could upgrade without having to do a dump and restore, then this wouldn't really be an issue. That's not really true. Have personally seen applications that places use and rely on that are not yet compatible with v 7.3.x, because the vendors of the applications compiled against something that was of version 7.2.x, and doesn't work with version 7.3.x. Now, that's not our fault, and not the fault of the places running the applications, it's just part of how PostgreSQL is applied out in the real world. :-) Regards and best wishes, Justin Clift -- My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there. - Indira Gandhi ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Anyone want to get involved in writing the the driver
Jeroen T. Vermeulen wrote: On Wed, Jan 15, 2003 at 01:20:45PM +1030, Justin Clift wrote: Have been discussing what it would take to write an SDBC driver for connecting StarOffice/OpenOffice to PostgreSQL with Frank Schönheit, a senior member of the Sun StarOffice/OpenOffice DBA team, and a few senior members of the OpenOffice project. I think something like this is already being done based on libpqxx. See http://gborg.postgresql.org/project/libpqxx/bugs/bugupdate.php?403 for a feature request related to this work. Thanks Jeroen, it's good news. That's a bug filed by Peter Novodvorsky, but haven't seen him using that email address before. He's a pretty decent guy that started writing a PostgreSQL SDBC driver for OpenOffice many months ago, but seemed to have stopped and dropped out of sight. Looks like he might still be working on it. Will ask him, see how far he's gotten, how much more is needed, and so forth. :-) Regards and best wishes, Justin Clift Jeroen -- My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there. - Indira Gandhi ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] Survey results from the PostgreSQL portal page
Hi everyone, Dave Page put up a new survey on the PostgreSQL portal page very recently, What would attract the most new PostgreSQL users? and the results in already are interesting (1,529 results as this is being written): http://www.postgresql.org/survey.php?SurveyID=9 Listed from most voted for to least voted for we have: *** AnswerResponses Percentage More speed 505 33.028% Win32 Port 390 25.507% Replication 386 25.245% Better docs 160 10.464% More features 32 2.093% Better marketing 29 1.897% Better migration 18 1.177% PITR 9 0.589% Total number of responses: 1529 *** Now, we don't necessarily have a speed problem, as people who take the time to tune the database can attest to, so this is making me consider why such a large percentage of folk would vote for that. The possibilities that come to mind immediately are: + People don't know that they should tune the database, and are leaving the configuration settings at the defaults. We could adjust the perception of PostgreSQL's speed for these people by adjusting the default settings. We were already considering raising the memory buffer defaults weren't we? + People are having troubles related to VACUUM. This is being worked on presently isn't it? + People don't know *how* to tune the database properly yet? + Maybe we need more inbuilt self-tuning abilities or utilities for PostgreSQL? Other interesting conclusions can be drawn from the results too, one of which is that only about 2% of people are asking for more features, and also that only about 2% are looking for better marketing. Anyway, thought this worth bringing to people's attention, as we may find some value in it. :-) Regards and best wishes, Justin Clift -- My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there. - Indira Gandhi ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Survey results from the PostgreSQL portal page
On Sun, 2003-01-19 at 15:20, Justin Clift wrote: Now, we don't necessarily have a speed problem, as people who take the time to tune the database can attest to, so this is making me consider why such a large percentage of folk would vote for that. The possibilities that come to mind immediately are: + people measure postgresql by the speed of bulk imports which seem to be faster on other dbs (I'm only repeating what I often see on the lists), and don't consider that this is not something most people do on a regular basis. btw, PITR would get more hits if more people knew what it means... (Yes, I know what it is, but I think many who don't read the mailing lists etc. don't). cheers -- vbi -- featured link: http://fortytwo.ch/gpg/subkeys signature.asc Description: This is a digitally signed message part
Re: [HACKERS] Survey results from the PostgreSQL portal page
On Sunday 19 January 2003 09:20, Justin Clift wrote:
Dave Page put up a new survey on the PostgreSQL portal page very
recently, What would attract the most new PostgreSQL users? and the
results in already are interesting (1,529 results as this is being
written):
http://www.postgresql.org/survey.php?SurveyID=9
Listed from most voted for to least voted for we have:
***
AnswerResponses Percentage
More speed 505 33.028%
Win32 Port 390 25.507%
Replication 386 25.245%
Better docs 160 10.464%
More features 32 2.093%
Better marketing 29 1.897%
Better migration 18 1.177%
PITR 9 0.589%
Total number of responses: 1529
What I find interesting is that 25% voted for replication and only 1/2% voted
for PITR. I think that that shows that surveys are easily skewed by their
own parameters. People interested in both probably just voted for the one
slightly higher on their wish list.
Anyway, interesting straw vote but let's not make critical decisions based on
it. It's not even a vote of the people looking for databases. It's a vote
of what those people want in the opinion of the people who voted.
Now, we don't necessarily have a speed problem, as people who take the
time to tune the database can attest to, so this is making me consider
why such a large percentage of folk would vote for that.
Need for speed. It doesn't matter how fast we are, faster is always better.
Other items are of the nature have or not have a feature and people may
disagree whether we need the feature or not but who will ever say that more
speed is not wanted?
--
D'Arcy J.M. Cain darcy@{druid|vex}.net | Democracy is three wolves
http://www.druid.net/darcy/| and a sheep voting on
+1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner.
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Survey results from the PostgreSQL portal page
+ people measure postgresql by the speed of bulk imports This is a good point. I can complete agree. What we might need is something called SQL Loader or so. This may sound funny and it doesn't make technical sense but it is an OBVIOUS way of importing data. People often forget to use transactions or don't know about COPY. A perfectly documented tool called SQL Loader or so might help. This is mainly a marketing reason but according to the things I have seen this is true. + people think about MySQL and speed People and magazines have MySQL in mind and this is a point which annoys me most. Why don't they just think about SAP DB or Oracle instead of MontySQL. which seem to be faster on other dbs (I'm only repeating what I often see on the lists), and don't consider that this is not something most people do on a regular basis. btw, PITR would get more hits if more people knew what it means... (Yes, I know what it is, but I think many who don't read the mailing lists etc. don't). People with more experience will ask for more high level features. People need to get started quickly so that they will find out about the advantages of a database. Features have to be obvious because other way people with not much experience won't look for it. Also: At least once a week somebody is asking for replication. Replication, clustering, hot failover, and so forth are definitely the features which are asked by companies. I wonder why people ask for better documentation. I think the documentation is really good. Ever read Oracle stuff? *ugh*. Hans -- *Cybertec Geschwinde u Schoenig* Ludo-Hartmannplatz 1/14, A-1160 Vienna, Austria Tel: +43/1/913 68 09; +43/664/233 90 75 www.postgresql.at http://www.postgresql.at, cluster.postgresql.at http://cluster.postgresql.at, www.cybertec.at http://www.cybertec.at, kernel.cybertec.at http://kernel.cybertec.at ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Survey results from the PostgreSQL portal page
Justin Clift [EMAIL PROTECTED] writes: Dave Page put up a new survey on the PostgreSQL portal page very recently, What would attract the most new PostgreSQL users? and the results in already are interesting (1,529 results as this is being written): [snip] Now, we don't necessarily have a speed problem, as people who take the time to tune the database can attest to, so this is making me consider why such a large percentage of folk would vote for that. Interesting question. Too bad the survey didn't ask *what* they find slow. Other interesting conclusions can be drawn from the results too, one of which is that only about 2% of people are asking for more features, and also that only about 2% are looking for better marketing. Of course, this is a survey of people who already know about Postgres, and are sufficiently interested in using it to have visited the website. So really, people who need to be marketed to weren't surveyed. The low vote for that point is probably just survey skew. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Survey results from the PostgreSQL portal page
On Sun, Jan 19, 2003 at 09:43:03AM -0500, D'Arcy J.M. Cain wrote: What I find interesting is that 25% voted for replication and only 1/2% voted for PITR. I think that that shows that surveys are easily skewed by their own parameters. People interested in both probably just voted for the one slightly higher on their wish list. This one surprised me too. Almost all companies I talked to abolut PostgreSQL ask for PITR. Yes, many also ask for replication, but the amount is much lower. Michael -- Michael Meskes Email: [EMAIL PROTECTED] ICQ: 179140304 Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Survey results from the PostgreSQL portal page
I wonder why people ask for better documentation. I think the documentation is really good. Ever read Oracle stuff? *ugh*. They want examples of real-world usage. The commands themselves have good 'HOW TO' notes, and an explanation of what they are, but we don't really have anything on 'WHY?'. A large number of people coming from MySQL, or just starting out don't know what feature XYZ can do for them, and why it's best (easiest) for the database to do that work -- regardless of what that Java programmer thinks beans are for. Much of this can probably be borrowed from books on basics. -- Rod Taylor [EMAIL PROTECTED] PGP Key: http://www.rbt.ca/rbtpub.asc signature.asc Description: This is a digitally signed message part
Re: [HACKERS] Survey results from the PostgreSQL portal page
On Sun, 2003-01-19 at 14:20, Justin Clift wrote: Dave Page put up a new survey on the PostgreSQL portal page very recently, What would attract the most new PostgreSQL users? ... Other interesting conclusions can be drawn from the results too, one of which is that only about 2% of people are asking for more features, and also that only about 2% are looking for better marketing. I suspect the majority of those who responded are technical people who despise marketing. I also suspect that most people didn't answer the question asked but instead said what they themselves most wanted. But the only thing that will get many more users is much better marketing. If people don't hear about PostgreSQL, they will never even think of using it. I looked at the shelves of database books in Blackwells in Oxford yesterday: lots on Oracle and Sql Server and DB and several on MySQL. There were 2 on Postgresql, and only one copy of each. I'd be interested to know what the commercial PostgreSQL companies think about it -- Oliver Elphick[EMAIL PROTECTED] Isle of Wight, UK http://www.lfix.co.uk/oliver GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C The LORD is my strength and song, and he is become my salvation; he is my God, and I will prepare him an habitation; my father's God, and I will exalt him. Exodus 15:2 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Can we revisit the thought of PostgreSQL 7.2.4?
On Thu, 2003-01-16 at 22:47, Justin Clift wrote: Over the last few days we've had patches submitted for 7.2.3 that address a couple of things, both the WAL Recovery Bug that Tom has developed a patch for, and a couple of buffer overflows that have been widely reported. The buffer overflows, IMHO, are not sufficient reason to release an update. As Tom pointed out, there are lots of other, unpatched overflows in 7.2.3 (and the whole class of vulnerability requires SQL access to begin with). As for the WAL recovery bug, AFAIK no such bug has been reported in the last few days. Exactly what issue are you referring to? Cheers, Neil ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Suggestion for aggregate function
On 17 Jan 2003 19:08:06 -0500, Greg Stark [EMAIL PROTECTED] wrote: Would this query be efficient if there's an index on item_id, price ? That is, would it know to do an index scan Yes, at least to avoid the sort step. and be able to skip to the next item_id in the index as soon as a price was found? I don't think so. Look at how the index scan retrieves all rows: = EXPLAIN ANALYZE - SELECT DISTINCT ON (item) item, price, store FROM sale ORDER BY item, price; NOTICE: QUERY PLAN: Unique (cost=0.00..412.24 rows=1024 width=12) (actual time=0.93..549.95 rows=101 loops=1) - Index Scan using s_x1 on sale (cost=0.00..386.64 rows=10240 width=12) (actual time=0.90..399.52 rows=10240 loops=1) Total runtime: 551.55 msec EXPLAIN = DROP INDEX s_x1; DROP = EXPLAIN ANALYZE - SELECT DISTINCT ON (item) item, price, store FROM sale ORDER BY item, price; NOTICE: QUERY PLAN: Unique (cost=845.48..871.08 rows=1024 width=12) (actual time=941.83..1152.25 rows=101 loops=1) - Sort (cost=845.48..845.48 rows=10240 width=12) (actual time=941.71..1061.93 rows=10240 loops=1) - Seq Scan on sale (cost=0.00..163.40 rows=10240 width=12) (actual time=0.37..273.41 rows=10240 loops=1) Total runtime: 1304.63 msec Servus Manfred ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Can we revisit the thought of PostgreSQL 7.2.4?
Bruce Momjian wrote: Tom Lane wrote: snip PS: I'm not taking a position on Justin's suggestion that there should be a 7.2.4. Marc and Bruce would be the ones who have to do the work, so they get to make the decision... Who, us? Well, there is the confusion factor of releasing a patch to a superceeded major version. Wrapping it up and putting it out really isn't a big deal. Marc? Hi Marc, Would you be ok with us releasing a 7.2.4? :-) Regards and best wishes, Justin Clift -- My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there. - Indira Gandhi ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Survey results from the PostgreSQL portal page
On Sunday 19 January 2003 09:20, Justin Clift wrote: Dave Page put up a new survey on the PostgreSQL portal page very recently, What would attract the most new PostgreSQL users? and the results in already are interesting (1,529 results as this is being written): *** AnswerResponses Percentage More speed 505 33.028% Win32 Port 390 25.507% Replication 386 25.245% Better docs 160 10.464% More features 32 2.093% Better marketing 29 1.897% Better migration 18 1.177% PITR 9 0.589% Total number of responses: 1529 The funny thing is that, to me, this least is perfectly reflective of the FUD that other databases use against postgresql. It's too slow, it only runs on *nix, it doesn't have replication, and the documentation isn't very good. You can't FUD postgresql on feature set, becuase we have a pretty wide feature set (as good as any other open source rdbms afaik) plus it's open source, so if we don't have a feature that say oracle has, you can pay someone the $10,000+ the oracle license will cost to implement it. I've also not seen much FUD on the other issues either. If you can address the primary points that your competition is using as FUD, you will gain new users. We'll see what happens in 7.4 if we do have replication, native windows support, and PITR, because everyone will have to come up with some new FUD to sling this way. Robert Treat ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Survey results from the PostgreSQL portal page
-Original Message- From: Adrian 'Dagurashibanipal' von Bidder [mailto:[EMAIL PROTECTED]] Sent: 19 January 2003 14:47 To: PostgreSQL Hackers Mailing List Subject: Re: [HACKERS] Survey results from the PostgreSQL portal page btw, PITR would get more hits if more people knew what it means... (Yes, I know what it is, but I think many who don't read the mailing lists etc. don't). I've fixed that now. It ain't too pretty but it should appear after the next hourly site rebuild. Regards, Dave. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Survey results from the PostgreSQL portal page
Michael Meskes [EMAIL PROTECTED] wrote: Unfortunately it doesn't always work this way. I knew one government organization that decided to go for Oracle for 500K Euro instead of adding the missing features (actually almost exclusively PITR). One of the top arguments I heard was: I don't believe that free software community works. Once the developers get a social life or even kids, they stop working on software. Of course I told him that I still do work on free software despite having three sons on which he answered: Maybe, but I still don't believe it. Sad but true. I think it is about sustainability of free software. Linux kernel community gets many contributions and commitments from big IT companies, like Intel, IBM, NEC, etc. They throw many hackers into opensource community. So I think the linux kernel is getting more powerful and sustainable. Linux kernel can be trustful in the future? Yes, I think so. Even today, Oracle is running on Linux. In opensource community, I think only the developer pool can be guarantee for its sustainability. We need more developers and supporting companies. Can we get a belief in sustainability? BTW, Japanese government is considering the opensouce software. One official said, We don't want to pay more license fee to the proprietary software companies, like MS, Oracle or else. But we don't know how to keep the relationship with opensource community. The government may tend to be disliked by NPO(Non-profit organization) or else But he also said, NAIST(www.naist.go.jp) are going to replace *ALL* their software with opensource in next 2 years. I feel we are in the new movement now. We have a chance in our hands. Don't be disappointed. And my project is granted by IPA(www.ipa.go.jp) Japan. :-) -- NAGAYASU Satoshi [EMAIL PROTECTED] ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Can we revisit the thought of PostgreSQL 7.2.4?
Neil, Robert: As for the WAL recovery bug, AFAIK no such bug has been reported in the last few days. Exactly what issue are you referring to? That's my bug; I filed it on Wednesday. However, it is not 100%; that is: 1) While Tom and I are pretty sure that the issue *could* cause the behavior reported, we're not completely certain that it *did*; i.e. in the two reported cases, one actually turned out to be something else, and the other could possibly be something else as well. 2) Nobody has tested that switching the order of those 2 lines in 7.2.3 doesn't cause any problems, to date. I'm not saying that it's not potentially a patchable bug. We're just not ready to patch it yet. But I do vote for a 7.2.4 just because I can't upgrade a lot of my clients to 7.3.1 safely and there are a few easy patches for 7.2.3. Alternately, I would suggest an omnibus patch for the 7.2.3 source code so that we don't set a precedent for branching development. -- -Josh Berkus Aglio Database Solutions San Francisco ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Survey results from the PostgreSQL portal page
I wonder why people ask for better documentation. I think the documentation is really good. Ever read Oracle stuff? *ugh*. Ever read MySQL docs - *hack*!! Chris ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Survey results from the PostgreSQL portal page
Michael Meskes wrote: On Sun, Jan 19, 2003 at 01:19:03PM -0500, Robert Treat wrote: pretty wide feature set (as good as any other open source rdbms afaik) plus it's open source, so if we don't have a feature that say oracle has, you can pay someone the $10,000+ the oracle license will cost to implement it. I've also not seen much FUD on the other issues either. If you can Unfortunately it doesn't always work this way. I knew one government organization that decided to go for Oracle for 500K Euro instead of adding the missing features (actually almost exclusively PITR). One of the top arguments I heard was: I don't believe that free software community works. Once the developers get a social life or even kids, they stop working on software. Of course I told him that I still do work on free software despite having three sons on which he answered: Maybe, but I still don't believe it. Sad but true. Interesting observation, and not entirely irrelevant. It's the strength of any particular Open Source Community that seems to indicate whether or not there are going to be enough people getting involved to overcome the attrition rate of the people becoming less involved. With PostgreSQL, a lot of work goes into building and feeding the community. That includes making sure the right people are talking to each other, assisting people to find the information they need, and other simpler stuff like making sure the basic facilities work (cvs, ftp, websites, etc). We are fortunate in that being based on a BSD license is assisting businesses to adopt PostgreSQL without needing to think too hard about licensing ramifications, and we are also fortunate that the quality of PostgreSQL is extremely good and has an increasingly excellent reputation that is attracting people from countries all over the world to get involved. When people suggest that the Free Software Community doesn't work, it may be worthwhile pointing out that it works very well for the Communities that are strong, but he could be correct for those that haven't become self-sufficient yet. :-) Regards and best wishes, Justin Clift Michael -- My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there. - Indira Gandhi ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Survey results from the PostgreSQL portal page
On Mon, 20 Jan 2003, Christopher Kings-Lynne wrote: I wonder why people ask for better documentation. I think the documentation is really good. Ever read Oracle stuff? *ugh*. Ever read MySQL docs - *hack*!! The documentation definately needs work -- particularly client library documentation and PL/PgSQL. I want to work on this when I get time. Gavin ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[HACKERS] unquoted special constants
Hi, Is this the complete list of constants that must not be quoted? CURRENT_TIME CURRENT_TIMESTAMP CURRENT_DATE LOCAL_TIME LOCAL_TIMESTAMP CURRENT_USER SESSION_USER USER Anything else? (Aside from functions?) Chris ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Can we revisit the thought of PostgreSQL 7.2.4?
Josh Berkus wrote: Neil, Robert: As for the WAL recovery bug, AFAIK no such bug has been reported in the last few days. Exactly what issue are you referring to? That's my bug; I filed it on Wednesday. However, it is not 100%; that is: 1) While Tom and I are pretty sure that the issue *could* cause the behavior reported, we're not completely certain that it *did*; i.e. in the two reported cases, one actually turned out to be something else, and the other could possibly be something else as well. 2) Nobody has tested that switching the order of those 2 lines in 7.2.3 doesn't cause any problems, to date. I'm not saying that it's not potentially a patchable bug. We're just not ready to patch it yet. Ok, this might not be such an important fix after all then? The wording of it at the time did make it sound important, but if it somehow has bad interactions we would be shooting ourselves in the foot with it. Any guess-timates on it's safeness and whether it really would be beneficial? But I do vote for a 7.2.4 just because I can't upgrade a lot of my clients to 7.3.1 safely and there are a few easy patches for 7.2.3. Alternately, I would suggest an omnibus patch for the 7.2.3 source code so that we don't set a precedent for branching development. An interesting thought here is to know if Red Hat fixed *all* of the known PostgreSQL security flaws for 7.2.3 with their latest security release. It would be interesting to see their code if they did so, but from Tom's previous comments it would have meant a real lot of work. It's probably better to put out a 7.2.4 than an omnibus patch though, as it gives a better foundation for everyone working on 7.2.x to safely move to. From the viewpoint of it takes more skill to patch than to compile. Regards and best wishes, Justin Clift -- My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there. - Indira Gandhi ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Can we revisit the thought of PostgreSQL 7.2.4?
On Sunday 19 January 2003 22:16, Justin Clift wrote: An interesting thought here is to know if Red Hat fixed *all* of the known PostgreSQL security flaws for 7.2.3 with their latest security release. It would be interesting to see their code if they did so, but from Tom's previous comments it would have meant a real lot of work. Judge for yourself. Here's the text of the two Red Hat advisories (with the RPM listing and MD5 sums omitted): [For older versions] Red Hat, Inc. Red Hat Security Advisory Synopsis: Updated PostgreSQL packages fix buffer overrun vulnerabilities Advisory ID: RHSA-2003:010-10 Issue date:2003-01-14 Updated on:2003-01-14 Product: Red Hat Linux Keywords: PostgreSQL datetime lpad rpad multibyte Cross references: RHSA-2002:301 RHSA-2003:001 Obsoletes: CVE Names: CAN-2002-0972 CAN-2002-1397 CAN-2002-1398 CAN-2002-1400 CAN-2002-1401 CAN-2002-1402 - 1. Topic: Updated PostgreSQL packages are available for Red Hat Linux 6.2, 7, 7.1, and 7.2 where we have backported a number of security fixes. A separate advisory deals with updated PostgreSQL packages for Red Hat Linux 7.3 and 8.0. 2. Relevant releases/architectures: Red Hat Linux 6.2 - i386 Red Hat Linux 7.0 - i386 Red Hat Linux 7.1 - i386 Red Hat Linux 7.2 - i386, ia64 3. Problem description: PostgreSQL is an advanced Object-Relational database management system (DBMS). A number of security issues have been found that affect PostgreSQL versions shipped with Red Hat Linux. Buffer overflows in PostgreSQL 7.2 allow attackers to cause a denial of service and possibly execute arbitrary code via long arguments to the lpad or rpad functions. CAN-2002-0972 Buffer overflow in the cash_words() function for PostgreSQL 7.2 and earlier allows local users to cause a denial of service and possibly execute arbitrary code via a malformed argument. CAN-2002-1397 Buffer overflow in the date parser for PostgreSQL before 7.2.2 allows attackers to cause a denial of service and possibly execute arbitrary code via a long date string, also known as a vulnerability in handling long datetime input. CAN-2002-1398 Heap-based buffer overflow in the repeat() function for PostgreSQL before 7.2.2 allows attackers to execute arbitrary code by causing repeat() to generate a large string. CAN-2002-1400 Buffer overflows in circle_poly, path_encode and path_add allow attackers to cause a denial of service and possibly execute arbitrary code. Note that these issues have been fixed in our packages and in PostgreSQL CVS, but are not included in PostgreSQL version 7.2.2 or 7.2.3. CAN-2002-1401 Buffer overflows in the TZ and SET TIME ZONE enivronment variables for PostgreSQL 7.2.1 and earlier allow local users to cause a denial of service and possibly execute arbitrary code. CAN-2002-1402 Note that these vulnerabilities are only critical on open or shared systems because connecting to the database is required before the vulnerabilities can be exploited. The PostgreSQL Global Development Team has released versions of PostgreSQL that fixes these vulnerabilities, and these fixes have been isolated and backported to the various versions of PostgreSQL that originally shipped with each Red Hat Linux distribution. All users of PostgreSQL are advised to install these updated packages. 4. Solution: Before applying this update, make sure all previously released errata relevant to your system have been applied. Please note that this update is available via Red Hat Network. To use Red Hat Network, launch the Red Hat Update Agent with the following command: up2date This will start an interactive process that will result in the appropriate RPMs being upgraded on your system. Note that no initdb will be necessary from previous PostgreSQL packages. 5. RPMs required: [omitted] [For recent versions] Red Hat, Inc. Red Hat Security Advisory Synopsis: Updated PostgreSQL packages fix security issues and bugs Advisory ID: RHSA-2003:001-16 Issue date:2003-01-14 Updated on:2003-01-14 Product: Red Hat Linux Keywords: PostgreSQL VACUUM pre-1970 spinlock Cross references: Obsoletes: CVE Names: CAN-2002-0972 CAN-2002-1397 CAN-2002-1398 CAN-2002-1400 CAN-2002-1401 CAN-2002-1402 - 1. Topic: Updated PostgreSQL packages are available for Red Hat Linux 7.3 and 8.0. These packages correct several security and other bugs. A separate advisory deals with updated PostgreSQL packages for Red Hat Linux 6.2, 7, 7.1, and 7.2. 2. Relevant releases/architectures: Red Hat Linux 7.3 - i386 Red Hat Linux 8.0 - i386 3. Problem description: PostgreSQL is an advanced Object-Relational database management system. Red Hat Linux 7.3 shipped with PostgreSQL version 7.2.1.
Re: [HACKERS] Prepare enabled pgbench
Hi Curtis, Have you had time to get this done? :-) Regards and best wishes, Justin Clift Curtis Faith wrote: Tatsuo Ishii [EMAIL PROTECTED] writes: Thanks. I can commit it for 7.4. BTW, it would be nice if we could have a switch to turn on/off PREPARE/EXECUTE in pgbench so that we could see how PRPARE/EXECUTE could improve the performance... tom lane replies: That is a *must*. Otherwise, you've simply made an arbitrary change in the benchmark ... which is no benchmark at all. regards, tom lane I will add it as a switched option. It should be possible to keep most of the code common for the two cases. - Curtis ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] -- My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there. - Indira Gandhi ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] What goes into the security doc?
With reference to my post to the PostgreSQL Password Cracker on 2003-01-02, I've promised to write a security document for the project. Here it is, Sunday night, and I can't sleep. What better way to get there than start this task... My plan is to write this in very simple HTML. I will post the draft document on my website and post the URL here from time to time for feedback. Please make suggestions for content. So far, I will cover these items: - .pgpass (see http://developer.postgresql.org/docs/postgres/libpq-files.html) - local connections - remote connections (recommending SSL) - pg_hba (only in passing, most of that is at http://www.postgresql.org/idocs/index.php?client-authentication.html) - running the postmaster as a specific user That doesn't sound like much. Surely you can think of something else to add. Should I post this to another list for their views? OK, that's done it. I'm ready for sleep now. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] default to WITHOUT OIDS? Possible related problem
Tom Lane wrote: Daniel Kalchev [EMAIL PROTECTED] writes: If ever this happens, same should be considered for tables created via the SELECT INTO statement. These are in many cases 'temporary' in nature and do not need OIDs (while making much use of the OIDs counter). SELECT INTO does create tables without OIDs, as of 7.3. We've already had complaints about that ;-) I very recently updated one of my servers to 7.3.1. Various MS tools have started to give me guff when trying to access views in databases on that server through ODBC. Especially, MS Query (yes, I have some Excel users needing that) started complaining that this table has no OID, which really means that the ODBC driver complaints that ... Is that a side effect of the above problem ? Sincerely, Emmanuel Charpentier ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
