[HACKERS] RE: User locks code
At 09:39 AM 20-08-2001 -0700, Mikheev, Vadim wrote: If it does then one of the things I'd use it for is to insert unique data without having to lock the table or rollback on failed insert (unique index still kept as a guarantee). (Classic example how could be used SAVEPOINTs -:)) I guess so. But this could be faster. So, in your application you would first lock a key in excl mode (for duration of transaction), than try to select and insert unless found? (Note that this will not work with serializable isolevel.) yep: lock tablename.colname.val=1 select count(*) from tablename where colname=1 If no rows, insert, else update. (dunno if the locks would scale to a scenario with hundreds of concurrent inserts - how many user locks max?). Why wouldn't it work with serializable isolevel? Anyway, I believe that isolevel doesn't really serialise things in this case (inserting a unique row) so it wouldn't matter to me. Regards, Link. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[HACKERS] Re: encoding: ODBC, createdb
On Tue, Aug 21, 2001 at 10:00:50AM +0900, Tatsuo Ishii wrote: I found some other things: - why database encoding for new DB check 'createdb' script and not CREATE DATABASE statement? (means client only encodings, like BIG5)? Bug? Oh, that must be a bug. Do yo want to take care of it by yourself? I check and fix it. The 'createdb' script needn't check somethig, all must be in backend. Karel -- Karel Zak [EMAIL PROTECTED] http://home.zf.jcu.cz/~zakkr/ C, PostgreSQL, PHP, WWW, http://docs.linux.cz, http://mape.jcu.cz ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] encoding: ODBC, createdb
On Tue, Aug 21, 2001 at 10:00:21AM +0900, Hiroshi Inoue wrote: Karel Zak wrote: I found some other things: - ODBC -- here is some multibyte stuff too. Why ODBC code don't use pg_wchar.h where is all defined? In odbc/multibyte.h is again defined all encoding identificators. IMHO we can use for ODBC same solution as for libpq and compile it with encname.c file too. ODBC under Windows needs no source/header files in PostgreSQL other than in src/interfaces/odbc. It's not preferable for psqlodbc driver to be sensitive about other PostgreSQL changes because the driver has to be able to talk multiple versions of PostgreSQL servers. In fact the current driver could talk to any server whose version = 6.2(according to a person). As for pg_wchar.h I'm not sure if it could be an exception and we could expect for the maintainer to take care of ODBC. If I were he, I would hate it. In the odbc/multibyte.h is if (strstr(str, %27SJIS%27) || strstr(str, 'SJIS') || strstr(str, 'sjis')) ..and same line for BIG5 I add here new names 'Shift_JIS' and 'Big5' only. Karel -- Karel Zak [EMAIL PROTECTED] http://home.zf.jcu.cz/~zakkr/ C, PostgreSQL, PHP, WWW, http://docs.linux.cz, http://mape.jcu.cz ---(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] Postgresql log analyzer
Hi all, I'm currently trying to develop a log analyzer for PostgreSQL logs and at the first stage I'm finding a little problem with the postgresql.conf option log_timestamp. The problem is that if this option is set to false we have no idea of when the backend is started: DEBUG: database system was shut down at 2001-08-20 21:51:54 CEST DEBUG: CheckPoint record at (0, 126088776) DEBUG: Redo record at (0, 126088776); Undo record at (0, 0); Shutdown TRUE DEBUG: NextTransactionId: 489793; NextOid: 77577 DEBUG: database system is in production state Is it possible to have it into the last line as we have the information of the database shutdown timestamp in the first line ? Also, an other question is why using timestamp into the other log instead of the value of time in seconds since the Epoch like the time() function do ? I don't know if it is speedest or not but if timestamp is system local dependant I think it should be very difficult to me to have a portable log analyzer... Regards, Gilles Darold ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
[HACKERS] Re: encoding: ODBC, createdb
On Tue, Aug 21, 2001 at 10:00:50AM +0900, Tatsuo Ishii wrote: I found some other things: - why database encoding for new DB check 'createdb' script and not CREATE DATABASE statement? (means client only encodings, like BIG5)? Bug? Oh, that must be a bug. Do yo want to take care of it by yourself? I check and fix it. The 'createdb' script needn't check somethig, all must be in backend. Agreed. -- Tatsuo Ishii ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] PL/pgSQL bug?
Tom Lane wrote: Tatsuo Ishii [EMAIL PROTECTED] writes: NOTICE: ctid (0,5) xmin 645188 xmax 645190 cmin 2 cmax 2 This is odd too, since xmax 0 or cmax 0 should never happen with visible tuples, in my understanding. That's what the docs presently say, but they're in error --- nonzero xmax could represent a not-yet-committed deleting xact (or one that did commit, but not in your snapshot); or it could be from a deleting xact that rolled back. or it can come from referential integrity triggers: hannu=# create table parent(parid integer primary key); NOTICE: CREATE TABLE/PRIMARY KEY will create implicit index 'parent_pkey' for table 'parent' CREATE hannu=# create table child(cldid integer references parent on update cascade); NOTICE: CREATE TABLE will create implicit trigger(s) for FOREIGN KEY check(s) CREATE hannu=# insert into parent values(1); INSERT 20652 1 hannu=# insert into child values(1); INSERT 20653 1 hannu=# update parent set parid=2; UPDATE 1 hannu=# select xmin,xmax,cmin,cmax,parid from parent; xmin | xmax | cmin | cmax | parid --+--+--+--+--- 731 | 731 |0 |4 | 2 (1 row) Now I have a question: if xmax is not used in determining tuple visibility (as I had assumed earlier) then what is ? How does postgres decide that a tuple is deleted ? Hannu ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
[HACKERS] Link to bug webpage
If anyone was concerned about our bug database being visible and giving the impression we don't fix any bugs, see this URL: http://www.isthisthingon.org/nisca/postgres.html Not only does it show the problems he had with PostgreSQL, he uses our bug list as an example of how PostgreSQL isn't advancing or interested in fixing bug. We better remove that web page soon: http://www.ca.postgresql.org/bugs/bugs.php?2 -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Link to bug webpage
Thus spake Bruce Momjian
If anyone was concerned about our bug database being visible and giving
the impression we don't fix any bugs, see this URL:
http://www.isthisthingon.org/nisca/postgres.html
Jeez, Louise. Talk about a blaming the tools because you don't know
anything about database design. I mean, his biggest complaint is that
PostgreSQL makes it hard (not impossible as he implies) to change the
schema. Perhaps that is because it was written by GOOD database designers
who don't have to change their schema every other week and so that issue
hasn't been a squeaky wheel.
I can't believe that anyone important is listening to this guy.
--
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 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Link to bug webpage
We better remove that web page soon: http://www.ca.postgresql.org/bugs/bugs.php?2 Do we have any pages to alter the status of bugs, or assign them? There are a number of bugs in the list that I know are fixed. Philip Warner| __---_ Albatross Consulting Pty. Ltd. |/ - \ (A.B.N. 75 008 659 498) | /(@) __---_ Tel: (+61) 0500 83 82 81 | _ \ Fax: (+61) 0500 83 82 82 | ___ | Http://www.rhyme.com.au |/ \| |---- PGP key available upon request, | / and from pgp5.ai.mit.edu:11371 |/ ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Link to bug webpage
On Tue, 21 Aug 2001, Bruce Momjian wrote: If anyone was concerned about our bug database being visible and giving the impression we don't fix any bugs, see this URL: http://www.isthisthingon.org/nisca/postgres.html Not only does it show the problems he had with PostgreSQL, he uses our bug list as an example of how PostgreSQL isn't advancing or interested in fixing bug. We better remove that web page soon: http://www.ca.postgresql.org/bugs/bugs.php?2 I removed the link to the page a few days ago. I guess I should disable it as well. Woulda been a whole lot easier if the database was just updated periodically. Vince. -- == Vince Vielhaber -- KA8CSHemail: [EMAIL PROTECTED]http://www.pop4.net 56K Nationwide Dialup from $16.00/mo at Pop4 Networking Online Campground Directoryhttp://www.camping-usa.com Online Giftshop Superstorehttp://www.cloudninegifts.com == ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Link to bug webpage
At 08:32 21/08/01 -0400, Vince Vielhaber wrote: Yes but noone was interested in it. It's still there but you're really the first to show interest in about a year. That's good (and depressing); where are they? Philip Warner| __---_ Albatross Consulting Pty. Ltd. |/ - \ (A.B.N. 75 008 659 498) | /(@) __---_ Tel: (+61) 0500 83 82 81 | _ \ Fax: (+61) 0500 83 82 82 | ___ | Http://www.rhyme.com.au |/ \| |---- PGP key available upon request, | / and from pgp5.ai.mit.edu:11371 |/ ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Link to bug webpage
On Tue, 21 Aug 2001, Philip Warner wrote: We better remove that web page soon: http://www.ca.postgresql.org/bugs/bugs.php?2 Do we have any pages to alter the status of bugs, or assign them? There are a number of bugs in the list that I know are fixed. Yes but noone was interested in it. It's still there but you're really the first to show interest in about a year. Vince. -- == Vince Vielhaber -- KA8CSHemail: [EMAIL PROTECTED]http://www.pop4.net 56K Nationwide Dialup from $16.00/mo at Pop4 Networking Online Campground Directoryhttp://www.camping-usa.com Online Giftshop Superstorehttp://www.cloudninegifts.com == ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Link to bug webpage
On Tue, 21 Aug 2001, Bruce Momjian wrote: If anyone was concerned about our bug database being visible and giving the impression we don't fix any bugs, see this URL: http://www.isthisthingon.org/nisca/postgres.html Not only does it show the problems he had with PostgreSQL, he uses our bug list as an example of how PostgreSQL isn't advancing or interested in fixing bug. We better remove that web page soon: http://www.ca.postgresql.org/bugs/bugs.php?2 Ok the functionality as well as the menu item are gone. You do realize it's going to give the impression that we're trying to hide something, don't you? Vince. -- == Vince Vielhaber -- KA8CSHemail: [EMAIL PROTECTED]http://www.pop4.net 56K Nationwide Dialup from $16.00/mo at Pop4 Networking Online Campground Directoryhttp://www.camping-usa.com Online Giftshop Superstorehttp://www.cloudninegifts.com == ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Link to bug webpage
At 08:22 21/08/01 -0400, Vince Vielhaber wrote: I removed the link to the page a few days ago. I guess I should disable it as well. Woulda been a whole lot easier if the database was just updated periodically. I don't think this is a good solution. We really do need a list of bugs. We probably need to list status and the releases they apply to. I don't think anybody but the most naieve (or biased) users expect software to be bug free, and the number of bugs grows with the complexity of the components. The fact we have a lot of bugs is to be expected. The fact that we don't mark them as fixed is just sloppy. Please reinstate the page, and allow some facility to edit them. I will try to work through them *slowly* to verify they are reproducible/not reproducible in 7.1.3 and in the current CVS, then mark them as fixed in the appropriate release. Hopefully other people will do the same with bugs they know about. Does this seem reasonable? Philip Warner| __---_ Albatross Consulting Pty. Ltd. |/ - \ (A.B.N. 75 008 659 498) | /(@) __---_ Tel: (+61) 0500 83 82 81 | _ \ Fax: (+61) 0500 83 82 82 | ___ | Http://www.rhyme.com.au |/ \| |---- PGP key available upon request, | / and from pgp5.ai.mit.edu:11371 |/ ---(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] Link to bug webpage
Ok the functionality as well as the menu item are gone. You do realize it's going to give the impression that we're trying to hide something, don't you? Uh, what choices do we have? Do we want to update that database, seeing as only a small percentage of bug reports come in through that interface? There are over 400 in the database. If that's a small percentage then so be it, but it's still over 400 bugs that appear to have been ignored. Having a place to look up possible problems and seeing if there was a solution seems to be a plus to me, but if you don't want it it doesn't bother me either way. The lookups are currently disabled, ball's in your court. It's up to the group to decide. If we have a database of bugs, I think it has to be complete. I think a partial list is worse than no list at all. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(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] Link to bug webpage
On Tue, 21 Aug 2001, Bruce Momjian wrote: On Tue, 21 Aug 2001, Bruce Momjian wrote: If anyone was concerned about our bug database being visible and giving the impression we don't fix any bugs, see this URL: http://www.isthisthingon.org/nisca/postgres.html Not only does it show the problems he had with PostgreSQL, he uses our bug list as an example of how PostgreSQL isn't advancing or interested in fixing bug. We better remove that web page soon: http://www.ca.postgresql.org/bugs/bugs.php?2 Ok the functionality as well as the menu item are gone. You do realize it's going to give the impression that we're trying to hide something, don't you? Uh, what choices do we have? Do we want to update that database, seeing as only a small percentage of bug reports come in through that interface? There are over 400 in the database. If that's a small percentage then so be it, but it's still over 400 bugs that appear to have been ignored. Having a place to look up possible problems and seeing if there was a solution seems to be a plus to me, but if you don't want it it doesn't bother me either way. The lookups are currently disabled, ball's in your court. Vince. -- == Vince Vielhaber -- KA8CSHemail: [EMAIL PROTECTED]http://www.pop4.net 56K Nationwide Dialup from $16.00/mo at Pop4 Networking Online Campground Directoryhttp://www.camping-usa.com Online Giftshop Superstorehttp://www.cloudninegifts.com == ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
[HACKERS] Re: Link to bug webpage
We could install the Postgres version of Bugzilla. Yes, there's a version that runs on Postgres rather than MySQL. That way we don't have to maintain the bug system. Ok the functionality as well as the menu item are gone. You do realize it's going to give the impression that we're trying to hide something, don't you? Vince. Cheers, Colin ---(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] Link to bug webpage
On Tue, 21 Aug 2001, Bruce Momjian wrote: If anyone was concerned about our bug database being visible and giving the impression we don't fix any bugs, see this URL: http://www.isthisthingon.org/nisca/postgres.html Not only does it show the problems he had with PostgreSQL, he uses our bug list as an example of how PostgreSQL isn't advancing or interested in fixing bug. We better remove that web page soon: http://www.ca.postgresql.org/bugs/bugs.php?2 Ok the functionality as well as the menu item are gone. You do realize it's going to give the impression that we're trying to hide something, don't you? Uh, what choices do we have? Do we want to update that database, seeing as only a small percentage of bug reports come in through that interface? -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Link to bug webpage
It's up to the group to decide. If we have a database of bugs, I think it has to be complete. I think a partial list is worse than no list at all. I disagree. Unless you are omniscient, we will only ever have a partial list. Perhaps more importantly, the more common ones will be in the list, because the more often it's reported, the more likely someone will use the bug tool. If we develop a culture that says 'if it's on the bug list, it will get looked at', then more people will report bugs via the correct channels etc. That is the real question. Do we want to rely more heavily on a bug database rather than the email lists? I haven't heard many say they want that. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Re: Link to bug webpage
On Tue, 21 Aug 2001, Colin 't Hart wrote: We could install the Postgres version of Bugzilla. Yes, there's a version that runs on Postgres rather than MySQL. That way we don't have to maintain the bug system. And how does it know when bugs are fixed? Vince. -- == Vince Vielhaber -- KA8CSHemail: [EMAIL PROTECTED]http://www.pop4.net 56K Nationwide Dialup from $16.00/mo at Pop4 Networking Online Campground Directoryhttp://www.camping-usa.com Online Giftshop Superstorehttp://www.cloudninegifts.com == ---(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] Re: Link to bug webpage
Philip Warner wrote: I don't think this is a good solution. We really do need a list of bugs. We probably need to list status and the releases they apply to. Bugzilla can do this -- it has the concept of a Milestone and a Version. I don't think anybody but the most naieve (or biased) users expect software to be bug free, and the number of bugs grows with the complexity of the components. The fact we have a lot of bugs is to be expected. The fact that we don't mark them as fixed is just sloppy. Bugzilla makes it fairly painless to mark a bug as fixed. Please reinstate the page, and allow some facility to edit them. I will try to work through them *slowly* to verify they are reproducible/not reproducible in 7.1.3 and in the current CVS, then mark them as fixed in the appropriate release. Hopefully other people will do the same with bugs they know about. Does this seem reasonable? If we install Bugzilla (running on Postgres, not MySQL, obviously) we save ourselves the hassle of maintaining the bug system, and we can showcase that Postgres *can* be to back a web-based system :-) Cheers, Colin ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Link to bug webpage
Can someone point me to a bug that is _not_ on the TODO list? If not, what does a complete bug database do for us except list reported bugs and possible workarounds. Do you actually expect someone to go thru the 400+ items in the database and compare them to the TODO list? Seems to me that's something the maintainer of the TODO list would be doing. Can you point me to the form that gets something on the TODO list that the average user can use? Can you guarantee every bug will end up on the TODO list? Can you point me to the place on the TODO list when a user can look at to see if a bug has been fixed or even reported? I was just asking. If I have been missing stuff, I can see more value to a bug database. You're making more of an issue with all of this than there is. The TODO list has a purpose, as does CVS, as do the mailing lists, as does the regression database, as does the bugs database, as do the interactive docs, ... OK, what value does a bug database have over a TODO list? -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[HACKERS] Re: [PORTS] mx.rpm
On Tuesday 21 August 2001 05:30, Andy wrote: Where is the MX RPM ? I didn't see this in the 7.1.3 RPM, for RH 7.1 and also Mdk 8.0. And by the way, it was asked when I tried to install the PostgreSQL Python module. I know 7.1.2 RH 7.1 has this MX RPM. The 7.1 DB-API 2.0 Python client _requires_ mx to be installed, whether from RPM or from source. As a stopgap measure, I uploaded a version of the mx rpm with the last 7.1.2 RPMset. However, I can't really provide those dependencies forever. The mx rpm provided in the 7.1.2 download is still ok to use. I don't think I cleaned it out. Check on 'www.rpmfind.net' for an mx RPM for your distribution. Incidentally, the older PyGreSQL module doesn't require this -- but the newer pgdb module does. This is not documented in the main PostgreSQL documentation, either. D'Arcy may be able to provide a link to where this is documented properly. From rpmfind.net: (http://www.rpmfind.net//linux/RPM/rawhide/1.0/i386/RedHat/RPMS/mx-2.0.1-1.i386.html) The mx extensions for Python are a collection of Python software tools which enhance Python's usability in many areas. Any OS that ships PostgreSQL 7.1.x and doesn't ship mx has a broken PostgreSQL Python DB-API 2.0 client, AFAICT. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Link to bug webpage
Bruce Momjian [EMAIL PROTECTED] writes: We could try going the other way, attaching URL's to the TODO items so people can get more information about an existing bug. That might be worth doing, but I think it's mostly orthogonal to the question of a bug database. The set of problems that are (still) on the TODO list is just a small fraction of the set of bugs that someone might look in a bug database for --- anything that's already fixed in current sources is probably not going to be on TODO, if it ever got there at all (which easily-fixed problems do not). That is a good point. I remove items after we make a release, and we don't record quickly fixed items. I wonder if I should keep the HISTORY file updated more frequently so people can see what has been fixed from the previous release. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] Link to bug webpage
On Tue, 21 Aug 2001, Bruce Momjian wrote: Yes, but we have to add items that don't come in through the database, and mark them as done/duplicates if we want it to be useful. Not necessarily. If someone discovers one that's not in the database they'll add it. If it's already fixed it'll get closed out but will still be in the database. It's not intended to be a todo/isdone list or a development history reference. We have a TODO list and CVS for that stuff. How do you communicate that to people looking at the content? Do you put in big letters at the top, This list is not complete. The fact an items is missing from the list (new bug) is just as important as an item appearing on the list. Huh? A list of bugs is only as complete as those submitting to it ... its no more, or less, complete then a mailing list *shrug* Not really. The bug database only gets submissions from the web form, as far as I know. It doesn't get direct postings to the bugs list, and even then, lots of bugs aren't reported on the bugs list. If we open it up to all lists, it becomes identical to our mailing list archives. The comment above was saying showing some bugs is better than nothing, meaning do you show the list even if you know it isn't being maintained or updated. I think that is worse than not showing it at all. Now, if it was updated with all bugs as they come in, and updated as completed, that would be nice, but it is a lot of work and I am not sure if it is worth doing. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Link to bug webpage
How about we trial it, but with the understanding that bugs we fix will be marked as such? After all, every bug is given an ID, so whomever fixes the bug with that ID should also mark it off. Looking at the present situation, it seems we began a good idea, but never really followed through with it. Maybe it's time to. Philip seems to be volunteering for taking care of what's presently in there, can we also ask those [HACKERS] who commit fixes to mark them off? + Justin Bruce Momjian wrote: It's up to the group to decide. If we have a database of bugs, I think it has to be complete. I think a partial list is worse than no list at all. I disagree. Unless you are omniscient, we will only ever have a partial list. Perhaps more importantly, the more common ones will be in the list, because the more often it's reported, the more likely someone will use the bug tool. If we develop a culture that says 'if it's on the bug list, it will get looked at', then more people will report bugs via the correct channels etc. That is the real question. Do we want to rely more heavily on a bug database rather than the email lists? I haven't heard many say they want that. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(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 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Link to bug webpage
On Tue, 21 Aug 2001, Tom Lane wrote: Vince Vielhaber [EMAIL PROTECTED] writes: That is the real question. Do we want to rely more heavily on a bug database rather than the email lists? I haven't heard many say they want that. The database keeps track of it. When someone uses the bugtool to report a bug it's mailed to the bugs list. But the problem is the lack of feedback the other way. In my mind, and I think in the minds of the rest of the developers, the pgsql-bugs list is where bug discussions happen. That's not something I have any interest in trying to change. Thus, I see little point in trying to maintain a bug database that's separate from the pgsql-bugs archives. I still think a link to a searchable pgsql-bugs archive could replace this bug database very easily. Some of the discussions could go on for weeks. Are you saying that wading thru a few hundred posts to find out what a solution was is better than a quick searchable summary? Personally I don't care if the bugs form, database, or any of that gets used. But if anyone expects to get meaningful bug reports you better plan on coming up with something alot easier than a mailing list you have to subscribe to (or wait till approved) for your info. You need to ask yourself how many bugs wouldn't be reported if it was harder to report them. PostgreSQL is gaining in the number of users, it's gonna get a whole lot worse before it gets any better. Vince. -- == Vince Vielhaber -- KA8CSHemail: [EMAIL PROTECTED]http://www.pop4.net 56K Nationwide Dialup from $16.00/mo at Pop4 Networking Online Campground Directoryhttp://www.camping-usa.com Online Giftshop Superstorehttp://www.cloudninegifts.com == ---(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] Link to bug webpage
A web-based interface allows people to submit bug reports they might otherwise not be able to report. Not everyone is able/willing to sign-up to a mailing list, nor have newsfeed access. The one we have (had) allows the reporting, but has the flaw of not showing when something has been done about a bug. That could be fixed by either not keeping a history, or marking their status's as closed when done. At a minimum, I reckon we should have the web interface there, even if it just pipes the report to the mailing list and doesn't keep a history at all. + Justin Bruce Momjian wrote: Yes, but we have to add items that don't come in through the database, and mark them as done/duplicates if we want it to be useful. Not necessarily. If someone discovers one that's not in the database they'll add it. If it's already fixed it'll get closed out but will still be in the database. It's not intended to be a todo/isdone list or a development history reference. We have a TODO list and CVS for that stuff. How do you communicate that to people looking at the content? Do you put in big letters at the top, This list is not complete. The fact an items is missing from the list (new bug) is just as important as an item appearing on the list. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(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 -- 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://www.postgresql.org/search.mpl
Re: [HACKERS] Link to bug webpage
MySQL has to first add some features in order to have some bugs, don't they? :-) Some people crack me up in their opinions.. If it took him 6 hours to figure out int8 then I'm not really interested in anything else he has to say... Lord... -Mitch - Original Message - From: Bruce Momjian [EMAIL PROTECTED] To: PostgreSQL-development [EMAIL PROTECTED] Sent: Tuesday, August 21, 2001 7:05 AM Subject: [HACKERS] Link to bug webpage If anyone was concerned about our bug database being visible and giving the impression we don't fix any bugs, see this URL: http://www.isthisthingon.org/nisca/postgres.html Not only does it show the problems he had with PostgreSQL, he uses our bug list as an example of how PostgreSQL isn't advancing or interested in fixing bug. We better remove that web page soon: http://www.ca.postgresql.org/bugs/bugs.php?2 -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Link to bug webpage
On Tue, 21 Aug 2001, Bruce Momjian wrote: How about we trial it, but with the understanding that bugs we fix will be marked as such? After all, every bug is given an ID, so whomever fixes the bug with that ID should also mark it off. Looking at the present situation, it seems we began a good idea, but never really followed through with it. Maybe it's time to. Philip seems to be volunteering for taking care of what's presently in there, can we also ask those [HACKERS] who commit fixes to mark them off? Can someone point me to a bug that is _not_ on the TODO list? If not, what does a complete bug database do for us except list reported bugs and possible workarounds. Do you actually expect someone to go thru the 400+ items in the database and compare them to the TODO list? Seems to me that's something the maintainer of the TODO list would be doing. Can you point me to the form that gets something on the TODO list that the average user can use? Can you guarantee every bug will end up on the TODO list? Can you point me to the place on the TODO list when a user can look at to see if a bug has been fixed or even reported? You're making more of an issue with all of this than there is. The TODO list has a purpose, as does CVS, as do the mailing lists, as does the regression database, as does the bugs database, as do the interactive docs, ... Vince. -- == Vince Vielhaber -- KA8CSHemail: [EMAIL PROTECTED]http://www.pop4.net 56K Nationwide Dialup from $16.00/mo at Pop4 Networking Online Campground Directoryhttp://www.camping-usa.com Online Giftshop Superstorehttp://www.cloudninegifts.com == ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Link to bug webpage
Yes, but we have to add items that don't come in through the database, and mark them as done/duplicates if we want it to be useful. Not necessarily. If someone discovers one that's not in the database they'll add it. If it's already fixed it'll get closed out but will still be in the database. It's not intended to be a todo/isdone list or a development history reference. We have a TODO list and CVS for that stuff. How do you communicate that to people looking at the content? Do you put in big letters at the top, This list is not complete. The fact an items is missing from the list (new bug) is just as important as an item appearing on the list. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(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] Link to bug webpage
Vince Vielhaber [EMAIL PROTECTED] writes: That is the real question. Do we want to rely more heavily on a bug database rather than the email lists? I haven't heard many say they want that. The database keeps track of it. When someone uses the bugtool to report a bug it's mailed to the bugs list. But the problem is the lack of feedback the other way. In my mind, and I think in the minds of the rest of the developers, the pgsql-bugs list is where bug discussions happen. That's not something I have any interest in trying to change. Thus, I see little point in trying to maintain a bug database that's separate from the pgsql-bugs archives. I still think a link to a searchable pgsql-bugs archive could replace this bug database very easily. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] Link to bug webpage
Bruce Momjian writes: OK, what value does a bug database have over a TODO list? The former is a database, the latter is a flat-text file. The former is mult-user, the latter is single-user. You figure out the rest. ;-) Seriously, IMHO a real bug database would be useful. A number of solutions for this are available, including the one Vince developed. But I will refuse to participate in a bug database that ordinary users have write access to. The sort of stuff that comes in over the bug list and through whatever else just isn't filtered enough. But in an organization that claims to be professional, when users report an actual problem they expect to be able to track this problem. I keep track of the problems that seem important to me myself, because I have no other place to put this information. -- Peter Eisentraut [EMAIL PROTECTED] http://funkturm.homeip.net/~peter ---(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] Link to bug webpage
- Original Message - From: Bruce Momjian [EMAIL PROTECTED] Sent: Tuesday, August 21, 2001 8:48 AM On Tue, 21 Aug 2001, Bruce Momjian wrote: Not only does it show the problems he had with PostgreSQL, he uses our bug list as an example of how PostgreSQL isn't advancing or interested in fixing bug. We better remove that web page soon: http://www.ca.postgresql.org/bugs/bugs.php?2 Ok the functionality as well as the menu item are gone. You do realize it's going to give the impression that we're trying to hide something, don't you? Uh, what choices do we have? Do we want to update that database, seeing as only a small percentage of bug reports come in through that interface? Maybe a better solution for the short run would be return the page where it was, and but links to the pgsql-bugs and pgsql-hackers archives with some sort of exmplanatory saying that this is a *complete* (it must be complete of course) list of bugs, which are being extensively discussed in the these lists and fixed. Please, visit/search these mail archives for most up-to-date information blah blah blah One can invent some appropriate wording, I guess. But this atleast will show people that there's work acually going on, and on daily basis. And also a good idea to have Last updated time stamp on the page too... so it doesn't seem to be forgotten for ages.. S. ---(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] Link to bug webpage
Vince Vielhaber [EMAIL PROTECTED] writes: Some of the discussions could go on for weeks. Are you saying that wading thru a few hundred posts to find out what a solution was is better than a quick searchable summary? Given a threaded index, you aren't wading through a few hundred posts. Agreed, a nice canned database entry might be easier to look at, but who's going to expend the time to maintain the database? Unless someone actively takes responsibility for keeping the DB up to date, it'll be junk. So far I heard Philip say he'd be willing to check over some fraction of the existing entries, but I don't hear anyone wanting to take it on as a long-term commitment. You need to ask yourself how many bugs wouldn't be reported if it was harder to report them. Who said anything about making it harder to report them? The webform feeding into pgsql-bugs is just fine with me. Seems to me the discussion here is about how we keep track of the results of pgsql-bugs activity. regards, tom lane ---(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] Locale by default?
Hiroshi Inoue writes: I would object even if there's such a way. People in Japan have hardly noticed that the strange behabior is due to the strange locale(LC_COLLATE). I don't think we should design our systems in a way that inconveniences many users because some users are using broken operating systems. If Japanese users have not realized yet that the locale support they are using is broken, then it's not the right solution to disable it in PostgreSQL by default. In that case the problem would just persist for the system as a whole. The right solution is for them to turn off locale support in their operating system, the way it's supposed to be done. -- Peter Eisentraut [EMAIL PROTECTED] http://funkturm.homeip.net/~peter ---(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] Link to bug webpage
On Tue, 21 Aug 2001, Bruce Momjian wrote: Yes, but we have to add items that don't come in through the database, and mark them as done/duplicates if we want it to be useful. Not necessarily. If someone discovers one that's not in the database they'll add it. If it's already fixed it'll get closed out but will still be in the database. It's not intended to be a todo/isdone list or a development history reference. We have a TODO list and CVS for that stuff. How do you communicate that to people looking at the content? Actually right now I'm just trying to communicate that to you. Do you put in big letters at the top, This list is not complete. The fact an items is missing from the list (new bug) is just as important as an item appearing on the list. In any situation the list not being complete should be more than obvious. The important part here that seems to be slipping away is that noone is updating it when things are fixed (sans Phillip). Vince. -- == Vince Vielhaber -- KA8CSHemail: [EMAIL PROTECTED]http://www.pop4.net 56K Nationwide Dialup from $16.00/mo at Pop4 Networking Online Campground Directoryhttp://www.camping-usa.com Online Giftshop Superstorehttp://www.cloudninegifts.com == ---(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] Link to bug webpage
Do you actually expect someone to go thru the 400+ items in the database and compare them to the TODO list? Seems to me that's something the maintainer of the TODO list would be doing. Can you point me to the form that gets something on the TODO list that the average user can use? Can you guarantee every bug will end up on the TODO list? Can you point me to the place on the TODO list when a user can look at to see if a bug has been fixed or even reported? I was just asking. If I have been missing stuff, I can see more value to a bug database. You're making more of an issue with all of this than there is. The TODO list has a purpose, as does CVS, as do the mailing lists, as does the regression database, as does the bugs database, as do the interactive docs, ... OK, what value does a bug database have over a TODO list? History. Searchability. Doesn't include features to be addeed. Yea, they would be nice. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] RE: User locks code
yep: lock tablename.colname.val=1 select count(*) from tablename where colname=1 If no rows, insert, else update. (dunno if the locks would scale to a scenario with hundreds of concurrent inserts - how many user locks max?). I don't see problem here - just a few bytes in shmem for key. Auxiliary table would keep refcounters for keys. Why wouldn't it work with serializable isolevel? Because of selects see old database snapshot and so you wouldn't see key inserted+committed by concurrent tx. Vadim ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Link to bug webpage
On Tue, 21 Aug 2001, Bruce Momjian wrote: Can someone point me to a bug that is _not_ on the TODO list? If not, what does a complete bug database do for us except list reported bugs and possible workarounds. Do you actually expect someone to go thru the 400+ items in the database and compare them to the TODO list? Seems to me that's something the maintainer of the TODO list would be doing. Can you point me to the form that gets something on the TODO list that the average user can use? Can you guarantee every bug will end up on the TODO list? Can you point me to the place on the TODO list when a user can look at to see if a bug has been fixed or even reported? I was just asking. If I have been missing stuff, I can see more value to a bug database. You're making more of an issue with all of this than there is. The TODO list has a purpose, as does CVS, as do the mailing lists, as does the regression database, as does the bugs database, as do the interactive docs, ... OK, what value does a bug database have over a TODO list? History. Searchability. Doesn't include features to be addeed. Vince. -- == Vince Vielhaber -- KA8CSHemail: [EMAIL PROTECTED]http://www.pop4.net 56K Nationwide Dialup from $16.00/mo at Pop4 Networking Online Campground Directoryhttp://www.camping-usa.com Online Giftshop Superstorehttp://www.cloudninegifts.com == ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] PL/pgSQL bug?
Tom Lane wrote: Hannu Krosing [EMAIL PROTECTED] writes: Tom Lane wrote: That's what the docs presently say, but they're in error --- nonzero xmax could represent a not-yet-committed deleting xact (or one that did commit, but not in your snapshot); or it could be from a deleting xact that rolled back. or it can come from referential integrity triggers: Mmm, yeah, SELECT FOR UPDATE uses xmax to record the identity of a transaction that has a row locked for update. In this case the xact hasn't actually deleted the old row yet (and may never do so), but xmax is set as though it has. Now I have a question: if xmax is not used in determining tuple visibility (as I had assumed earlier) then what is ? There are additional status bits in each tuple (t_infomask) that distinguish these various situations. The xmax field alone doesn't tell you much, since you can't interpret it without context. As I understood it it should tell the trx id that invalidated this tuple, no ? If you must write t_infomask in the tuple anyhow, then why not clean up xmax on abort ? I'm not sure why we bother to make xmin/xmax/etc visible to applications. They're really of no value to an app AFAICS. I guess they used to be of value at the time when time travel was possible and people did use xmax for documented purposes, i.e. recording tuple's lifetime and not for other stuff, especially without cleaning up after trx abort ;) I agree that they are losing their utility as we are moving away from the original notion of transaction ids (and oids) as something permanent that could be used for time travel or system auditing and recommending peole who need such features to reimplement those at application level, with triggers and explicitly defined fields. -- Hannu ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Link to bug webpage
It's up to the group to decide. If we have a database of bugs, I think it has to be complete. I think a partial list is worse than no list at all. I disagree. Unless you are omniscient, we will only ever have a partial list. Perhaps more importantly, the more common ones will be in the list, because the more often it's reported, the more likely someone will use the bug tool. If we develop a culture that says 'if it's on the bug list, it will get looked at', then more people will report bugs via the correct channels etc. Philip Warner| __---_ Albatross Consulting Pty. Ltd. |/ - \ (A.B.N. 75 008 659 498) | /(@) __---_ Tel: (+61) 0500 83 82 81 | _ \ Fax: (+61) 0500 83 82 82 | ___ | Http://www.rhyme.com.au |/ \| |---- PGP key available upon request, | / and from pgp5.ai.mit.edu:11371 |/ ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Link to bug webpage
That is the real question. Do we want to rely more heavily on a bug database rather than the email lists? I haven't heard many say they want that. The database keeps track of it. When someone uses the bugtool to report a bug it's mailed to the bugs list. Yes, but we have to add items that don't come in through the database, and mark them as done/duplicates if we want it to be useful. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] PL/pgSQL bug?
Hannu Krosing [EMAIL PROTECTED] writes: Tom Lane wrote: That's what the docs presently say, but they're in error --- nonzero xmax could represent a not-yet-committed deleting xact (or one that did commit, but not in your snapshot); or it could be from a deleting xact that rolled back. or it can come from referential integrity triggers: Mmm, yeah, SELECT FOR UPDATE uses xmax to record the identity of a transaction that has a row locked for update. In this case the xact hasn't actually deleted the old row yet (and may never do so), but xmax is set as though it has. Now I have a question: if xmax is not used in determining tuple visibility (as I had assumed earlier) then what is ? There are additional status bits in each tuple (t_infomask) that distinguish these various situations. The xmax field alone doesn't tell you much, since you can't interpret it without context. I'm not sure why we bother to make xmin/xmax/etc visible to applications. They're really of no value to an app AFAICS. regards, tom lane ---(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] Link to bug webpage
On Tue, 21 Aug 2001, Bruce Momjian wrote: That is the real question. Do we want to rely more heavily on a bug database rather than the email lists? I haven't heard many say they want that. The database keeps track of it. When someone uses the bugtool to report a bug it's mailed to the bugs list. Yes, but we have to add items that don't come in through the database, and mark them as done/duplicates if we want it to be useful. Not necessarily. If someone discovers one that's not in the database they'll add it. If it's already fixed it'll get closed out but will still be in the database. It's not intended to be a todo/isdone list or a development history reference. We have a TODO list and CVS for that stuff. Vince. -- == Vince Vielhaber -- KA8CSHemail: [EMAIL PROTECTED]http://www.pop4.net 56K Nationwide Dialup from $16.00/mo at Pop4 Networking Online Campground Directoryhttp://www.camping-usa.com Online Giftshop Superstorehttp://www.cloudninegifts.com == ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] Link to bug webpage
Philip Warner [EMAIL PROTECTED] writes: Please reinstate the page, and allow some facility to edit them. I will try to work through them *slowly* to verify they are reproducible/not reproducible in 7.1.3 and in the current CVS, then mark them as fixed in the appropriate release. Hopefully other people will do the same with bugs they know about. I think you are wasting your time, unless you can get the community as a whole to buy into the notion that it's a profitable use of our time to try to maintain this bug database. Personally I won't spend any time on it, because it has exactly the same flaws that made our previous experiment in bug-tracking go down in flames: it's incomplete (doesn't track bugs reported via the mailing lists) and at the same time too complete (tracks everything sent in via that web form, which includes a lot of non-bugs). Vince, if I were you I'd just make the page point to the pgsql-bugs archives (http://www.ca.postgresql.org/mhonarc/pgsql-bugs/), which at least gives people the right impression about activity. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Link to bug webpage
On Tue, 21 Aug 2001, Bruce Momjian wrote: Yes, but we have to add items that don't come in through the database, and mark them as done/duplicates if we want it to be useful. Not necessarily. If someone discovers one that's not in the database they'll add it. If it's already fixed it'll get closed out but will still be in the database. It's not intended to be a todo/isdone list or a development history reference. We have a TODO list and CVS for that stuff. How do you communicate that to people looking at the content? Do you put in big letters at the top, This list is not complete. The fact an items is missing from the list (new bug) is just as important as an item appearing on the list. Huh? A list of bugs is only as complete as those submitting to it ... its no more, or less, complete then a mailing list *shrug* ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Link to bug webpage
Vince Vielhaber [EMAIL PROTECTED] writes: Some of the discussions could go on for weeks. Are you saying that wading thru a few hundred posts to find out what a solution was is better than a quick searchable summary? Given a threaded index, you aren't wading through a few hundred posts. Agreed, a nice canned database entry might be easier to look at, but who's going to expend the time to maintain the database? Unless someone actively takes responsibility for keeping the DB up to date, it'll be junk. So far I heard Philip say he'd be willing to check over some fraction of the existing entries, but I don't hear anyone wanting to take it on as a long-term commitment. We could try going the other way, attaching URL's to the TODO items so people can get more information about an existing bug. We already have that for TODO.detail but we could certainly expand on that. In fact, it may be interesting to load the TODO list into a database and start attaching emails to individual items. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Link to bug webpage
On Tue, Aug 21, 2001 at 09:51:29AM -0400, Bruce Momjian wrote: It's up to the group to decide. If we have a database of bugs, I think it has to be complete. I think a partial list is worse than no list at all. I disagree. Unless you are omniscient, we will only ever have a partial list. Perhaps more importantly, the more common ones will be in the list, because the more often it's reported, the more likely someone will use the bug tool. If we develop a culture that says 'if it's on the bug list, it will get looked at', then more people will report bugs via the correct channels etc. That is the real question. Do we want to rely more heavily on a bug database rather than the email lists? I haven't heard many say they want that. I think this is related to the discussions about what to do with extensions, etc. The project is outgrowing its infrastructure. A bug database is one of those things that is hard to justify and maintain when all the developers can keep up with all the mailing lists, but that hasn't been true for a while, now. The _need_ for a bug database was recognized, but there wasn't enough interest for someone to take on the maintenance. As new developers have come in and taken over things like the JDBC driver, and the ODBC driver, no one has the entire state of the code in their head anymore. And, I think the project has reached critical mass: attracting new developers is not a big problem - other projects are taking PostgreSQL up as their base, without any selling from the core developers. Perhaps trying again (either with the existing system, or the PostgreSQL based Bugzilla) is the right answer. Personally, I think a bug database that coordinates with the email archives is the best of both worlds. That way, discussion about a bug, and it's state all get archived in the same location, without a lot of extra bother on the parts of the developers, just make sure to CC: the bug system. Call for volunteers who wish to be involved in the maintenence, open up the system, and put it on the list of TODO for release: 'check status and usefulness of current bug reporting system' so it gets looked at again at regular, appropriate intervals. Ross ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Link to bug webpage
On Tuesday 21 August 2001 11:59, Vince Vielhaber wrote: On Tue, 21 Aug 2001, Lamar Owen wrote: Red Hat makes mission-critical use of bugzilla running on Oracle. See bugzilla.redhat.com. And ask the Red Hat people on these lists their opinions of bugzilla. What who thinks of what has actually become irrelevant. Not really. I like to see what works for other projects before passing judgment -- and bugzilla and bug trackers of like bent are working very well for other projects. Red Hat is just one of the largest such 'projects.' The following is clear: o No tool will replace the mailing lists o The mailing lists are where discussion will be held o Many/most maintainers have no desire to update bug reports Ok, having been involved in a project that has both an active mailing list AND a bug tracker, I can comment on this. I am not interested in finding a mailing list _replacement_. I am, however, interested in finding a augmentative solution that does well what mailing lists do not do well. Mailing lists do many things well, but they do not do the business of bugtracking well. Particularly as the size and scope of the project goes up. Bug trackers do not do the thing of discussion well. They do, however, do the thing of bug status reporting _very_ well. They also do the thing of relating bugs to OS versions, releases, and libraries much easier than with a list. Reference the '7.1.2-3' patch bug sent last week. Much was said that was not at all related to the real problem -- Windows 98. While the new fts mailing list search is VERY nice, mailing list bug reports and the discussion that follows may or may not help someone down the road. IOW, just how useful are our [BUGS] archives from two years ago? Just how useful are any of our archives, for that matter? I have found them useful on occassion -- but those occassions are rather rare and usually are just to remember what _I_ said about something. Or to see what Tom Lane's first post was. Or to see how long somebody has been with the project. Etc. I don't want to see the searchable archives go away, of course -- but I am questioning how useful they are to _non-developers_. A dynamic tracker would show bugs that were fixed at various versions. It would also make the project seem more responsive to those not on the lists --the vast majority of our users likely don't even know these lists are as useful as they are. I had used PostgreSQL for two years before I found out that the mailling lists are where _it's_ happening. I was _amazed_ at these lists and their contents. And I ran a Usenet site ten years ago, at that. Maybe that was the source of my amazement, OTOH. I've been through news.groups wars, news.admin wars, etc. There weren't any real 'wars' here --and that was _different_. JMHO, of course. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] List response time...
Hi All, Looking at my message about the bug webpage and some other posts, I see that it was delayed for about 2h and a half. Some of the post were delayed for days... Why is that? Looks like the list has problems of some sort which cause these irregular delays. Just an annoying observation. S. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[HACKERS] Current CVS is broken
gcc -g -Wall -Wmissing-prototypes -Wmissing-declarations -I../../../src/include -c -o auth.o auth.c In file included from auth.c:22: /usr/include/sys/ucred.h:50: `NGROUPS' undeclared here (not in a function) % uname -a FreeBSD xor 4.3-STABLE FreeBSD 4.3-STABLE #2: Thu May 24 14:05:34 MSD 2001 teodor@xor:/usr/src/sys/compile/XOR i386 -- Teodor Sigaev [EMAIL PROTECTED] ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
RE: [HACKERS] User locks code
Regarding the licencing of the code, I always release my code under GPL, which is the licence I prefer, but my code in the backend is obviously released under the original postgres licence. Since the module is loaded dynamically and not linked into the backend I don't see a problem here. The problem is how to use user-locks in commercial projects. Some loadable interface functions are required to use in-backend user lock code, but interface is so simple - if one would write new functions they would look the same as yours covered by GPL. If the licence becomes a problem I can easily change it, but I prefer the GPL if possible. Actually I don't see why to cover your contrib module by GPL. Not so much IP (intellectual property) there. Real new things which make new feature possible are in lock manager. Vadim ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Link to bug webpage
On Tue, 21 Aug 2001, Lamar Owen wrote: [...] What who thinks of what has actually become irrelevant. The following is clear: o No tool will replace the mailing lists o The mailing lists are where discussion will be held o Many/most maintainers have no desire to update bug reports disadvantages of a mailinglist: - easy problems are solved by 10 people in 5 minutes, hard ones often by none - not clear who is the owner of a problem OK so what we need is an enhaced mailinglist with a web interface. I've used wreq (http://www.math.duke.edu/~yu/wreq/) in the past for something similar. Features: - web and mail interface - each problem gets an assigned owner - status of entered items is clear - not much extra work in comparison to a mailinglist. - outstanding bugs stay visible until closed (instead of forgotten) It may not be ideal for this kind of thing, but it is a start. Has anyone suggestions for a better tool? Reinoud ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
[HACKERS] query column def
Hi; I am reverse engineering a PostgreSQL database by querying catalog tables. I have run into a problem where I can not determine the exact info used in i.e. the CREATE TABLE statement. For example; how to determine the exact precision/length and scale used in a NUMERIC(p,s) column def. Looking at the PostgreSQL ODBC driver I see that it does some funky stuff such as reporting VARCHAR(maxlen) instead of i.e. VARCHAR(50) or whatever the column def was. So it appears that the author had similar problems. The result is that the ODBC driver does not appear to be absolutely accurate. Is this information availible somewhere in the catalog tables? Peter ---(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] query column def
Peter Harvey [EMAIL PROTECTED] writes: Is this information availible somewhere in the catalog tables? Yes, in the atttypmod column of pg_attribute. I'd recommend looking at psql's \d commands (describe.c), or at pg_dump, to see the approved way to retrieve catalog info. Those are kept up to date pretty faithfully, whereas other interfaces aren't necessarily. (Feel free to submit a patch to fix ODBC...) regards, tom lane ---(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] Link to bug webpage
Justin Clift [EMAIL PROTECTED] writes: After all, every bug is given an ID, so whomever fixes the bug with that ID should also mark it off. Oh? I've never seen a bug ID. Certainly the traffic in pgsql-bugs doesn't show any such thing. This isn't going to happen unless there's some fairly convenient mechanism to make it happen *in the context of responding to email on the pgsql-bugs list*. At the very least, the webform should add a link to an appropriate status-update page to the mail that it forwards to the list. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Postgresql log analyzer
Gilles DAROLD writes: Is it possible to have it into the last line as we have the information of the database shutdown timestamp in the first line ? We not just turn time stamping on? Also, an other question is why using timestamp into the other log instead of the value of time in seconds since the Epoch like the time() function do ? Because humans generally reckon time the former way. I don't know if it is speedest or not but if timestamp is system local dependant I think it should be very difficult to me to have a portable log analyzer... In the current system, the timestamp is not locale dependent, but that doesn't mean that it could be in the future. (I wouldn't find it particularly useful, because the current format is internationally readable.) What *is* locale dependent are the messages, though. Not sure how you plan to deal with that. -- Peter Eisentraut [EMAIL PROTECTED] http://funkturm.homeip.net/~peter ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] Re: Link to bug webpage
I know I am not on the kernel team, but I have been a software developer for almost 20 years. ;-) A bug database is a useful tool IF it has been setup to be so. If it is a bare bones repository for bug reports it will not work. People won't use it. A good bug database, i.e. one which will be used, must be administered, and that administration must be easier than dealing with the various items separately. Also, there should be approved severity numbers, and a difference between entered and confirmed bugs, especially if you allow external access to the database. For what it is worth, a good bug database, which is used and reliable, would do much for PostgreSQL's reputation in the commercial IT space. The danger is that a bad or unused bug database would probably do more harm than not having one. Bruce Momjian wrote: If anyone was concerned about our bug database being visible and giving the impression we don't fix any bugs, see this URL: http://www.isthisthingon.org/nisca/postgres.html Not only does it show the problems he had with PostgreSQL, he uses our bug list as an example of how PostgreSQL isn't advancing or interested in fixing bug. We better remove that web page soon: http://www.ca.postgresql.org/bugs/bugs.php?2 -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Link to bug webpage
Ross J. Reedstrom [EMAIL PROTECTED] writes: The project is outgrowing its infrastructure. Perhaps so. I think what's *really* needed here is someone who is willing to take responsibility for maintaining a bug database, ie, removing cruft (non-bug messages), making sure that old bugs are marked closed when a developer forgets to do it, etc etc. It doesn't matter what automatic systems we have in place unless a human is willing to take responsibility for quality control. But given a volunteer, a bug database could be a really nice thing to have. If we're getting as big as all that, a volunteer or three to do this shouldn't be impossible to come by. I think a bug database that coordinates with the email archives is the best of both worlds. That way, discussion about a bug, and it's state all get archived in the same location, without a lot of extra bother on the parts of the developers, just make sure to CC: the bug system. I like that idea a lot: just cc: to some bug-input address to add or update the collected mail for any one bug. Peter remarked that he wouldn't use a bug database unless it has some input filtering to remove all the non-bug issues that currently clutter the pgsql-bug archives. I tend to agree with him. A possible way to handle that is to set up bug-input like a closed mailing list: only accept mail from designated people (developers and people nominated to help run the bug database). So, a bug database entry would start life when some one of these people replies to an emailed bug report confirming that there is a bug, or forwards the verified report to bug-input, or whatever. It'd still need a maintainer, but something like this would fit comfortably into our existing habits, which a pure web-based system won't. So: any volunteers to set this up and help run it? regards, tom lane ---(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] Locale by default?
I would object even if there's such a way. People in Japan have hardly noticed that the strange behabior is due to the strange locale(LC_COLLATE). I don't think we should design our systems in a way that inconveniences many users because some users are using broken operating systems. If Japanese users have not realized yet that the locale support they are using is broken, then it's not the right solution to disable it in PostgreSQL by default. In that case the problem would just persist for the system as a whole. The right solution is for them to turn off locale support in their operating system, the way it's supposed to be done. I do not agree with your above statement, I would also want a way to turn it off in PostreSQL alone and leave the OS and rest as is (without a need to worry about). (Our admins use C, En_US, De_DE, De_AT here, but no locale support in the db) Imho we also need to keep in mind that other DB's don't create locale aware char columns by default eighter (they have nchar or some other extended create table syntax). Andreas ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Link to bug webpage
On Tuesday 21 August 2001 11:06, Mitch Vincent wrote: Some people crack me up in their opinions.. If it took him 6 hours to figure out int8 then I'm not really interested in anything else he has to say... Lord... Hmmm... Let's look at the guy's bulleted list. The first item he can't stand is that you can't add a column after any arbitrary column, that it goes at the end. Well, this is really clueless, as you order the columns when you SELECT or when the application presents the data. The second item, however, has some real meat in it. Don't tell me that I should have a correct design before writing any application code. Any programmer knows that the user's needs change over time -- and the database should be able to keep up without any problems. I have myself ran into PostgreSQL's ALTER-hostile environment. I'm patient, however, as I need the featureset. Our ALTER needs real muscle. Some things are already on our TODO list to fix this, though -- and this guy should have checked that. But maybe he didn't find our TODO list. And 7.1 is much better than 7.0.3, the version he looked at. That third item, about int8. Can a clueless newbie who's heard that PostgreSQL is so great, knowing NOTHING about it, find things reasonably well in the docs? Only clueless newbies should answer that question -- I, nor any developer, qualify to answer that question. The fourth item looks like whining, IMHO. The problem he describes is merely annoying to him -- yet it's bulleted. Sounds like a MySQL partisan who's upset that PostgreSQL is better at many things and is trying to justify not supporting PostgreSQL out of personal bias. However, if it weren't too difficult to support index creation at table creation time, why NOT allow that? Do we just not _want_ to do it? I didn't see it in my read of TODO. Of course, the guy didn't ask on the lists to have it put in TODO. But how would he know to ask to have something put in TODO? Our development process is very simple, but is also rather opaque to outsiders. Maybe that's a good thing; maybe that's bad. Should we let just any user know that if they want a feature, they need to ask to have it placed on TODO? Or are people really not reading the docs? (Experienced admins know the answer to THATquestion.) Our documentation is, however, much better now than when I started. Kudos to Thomas and all the rest that have contributed. I also like the direction techdocs.postgresql.org is going. The last worthwhile item on this guy's list is changing ownership of a database. Well, I haven't yet had to do this: can we do this easily? Just because someone is clueless and even obnoxious in their comments doesn't automatically disqualify what they say from validity. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
RE: [HACKERS] Locale by default?
Face it, everything has locale support these day. PostgreSQL is one of the few packages that even has it as an option to turn it off. Users of binary packages of PostgreSQL are all invariably faced with locale features. So it's not like sudden unasked-for locale support is going to be a major shock. What makes you so opposed to a GUC for disabling locale support ? Andreas ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Link to bug webpage
How about we trial it, but with the understanding that bugs we fix will be marked as such? After all, every bug is given an ID, so whomever fixes the bug with that ID should also mark it off. Looking at the present situation, it seems we began a good idea, but never really followed through with it. Maybe it's time to. Philip seems to be volunteering for taking care of what's presently in there, can we also ask those [HACKERS] who commit fixes to mark them off? Can someone point me to a bug that is _not_ on the TODO list? If not, what does a complete bug database do for us except list reported bugs and possible workarounds. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
RE: [HACKERS] Progress report on locale safe LIKE indexing
If your solution is short-lived, your change would be not only useless but also harmful. So I expect locale-aware people to confirm that we are in the right direction. I am a bit confused here. We have tinkered with LIKE indexing at least a year. Now that a solution is found that *works*, it is claimed that it is harmful because LIKE was doing the wrong thing in the first place. OTOH, I have not seen anyone independently claim that LIKE is wrong, nor do I see anyone proposing to actually change it. Because we configure --without-locale ? How should we see or object to wrong behavior in a part of the software we don't need or use ? Andreas ---(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] RE: User locks code
Mikheev, Vadim [EMAIL PROTECTED] writes: (dunno if the locks would scale to a scenario with hundreds of concurrent inserts - how many user locks max?). I don't see problem here - just a few bytes in shmem for key. Auxiliary table would keep refcounters for keys. I think that running out of shmem *would* be a problem for such a facility. We have a hard enough time now sizing the lock table for system locks, even though they use fixed-size keys and the system as a whole is designed to ensure that not too many locks will be held simultaneously. (For example, SELECT FOR UPDATE doesn't try to use per-tuple locks.) Earlier in this thread, someone proposed using user locks as a substitute for SELECT FOR UPDATE. I can guarantee you that that someone will run out of shared memory before long, if the userlock table resides in shared memory. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] List response time...
On Tuesday 21 August 2001 12:59, Serguei Mokhov wrote: Looking at my message about the bug webpage and some other posts, I see that it was delayed for about 2h and a half. Some of the post were delayed for days... Why is that? Looks like the list has problems of some sort which cause these irregular delays. Mailing lists don't scale well to large numbers of subscribers. I see this delay constantly,on multiple lists. The bigger the list gets, the slower the list gets (and the more loaded the server gets, right Marc? :-)). Newsgroups scale a little better, but Usenet propagation delay was a problem even when full feeds were below 100MB per day. Actually, Usenet propagation is better now than then, now that the majority of sites aren't uucp and fed batched with C-News. (or BNews, even). Usenet propagation delays used to be measured in days and sometimes weeks. To get a message in two days was great time! But I can remember when Usenet propagation delays were how you judged EXPIRE times and newsspool size. And I also remember nasty tricks used when servers that didn't respect 'distribution:' were hit with 'expires:' headers with values below the mean propagation delay.and I can recall getting CANCELS for postings two days before the posting to be canceled came trickling in We're still not as bad as BugTraq, though. Not only is the message delayed two to three days, other people will have already replied to it, and discussion will have been closed off before I ever get a chance to say anything. Well, maybe that's a good thing. :-) I guess this IS one of the few advantages of having to use reply-all on this list Although then the discussion has moved on before the general list membership has had a chance to read most of the recent replies The best thing to do is simply to expect propagation delay. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
RE: [HACKERS] Progress report on locale safe LIKE indexing
Zeugswetter Andreas SB SD writes: I am a bit confused here. We have tinkered with LIKE indexing at least a year. Now that a solution is found that *works*, it is claimed that it is harmful because LIKE was doing the wrong thing in the first place. OTOH, I have not seen anyone independently claim that LIKE is wrong, nor do I see anyone proposing to actually change it. Because we configure --without-locale ? How should we see or object to wrong behavior in a part of the software we don't need or use ? Wrong answer. Read my second sentence again and compare it to your first sentence. -- Peter Eisentraut [EMAIL PROTECTED] http://funkturm.homeip.net/~peter ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
[HACKERS] request, if not already available.
I need to manage a large number of various databases, some assigned to different people, others only internal to the company I work for. I would like to be able to update the pg_hba.conf file from inside a psql console connection but only if I an connected to template1 AND the main postgres user. I don't want to have to connect to the database machine via a different means because it's a step that can be forgotten very easily. If I had the option to be able to create a new pg_hba.conf entry then I could remember to do it right after I create a new database, and a user for it. Chris Bowlby, - Web Developer @ Hub.org. [EMAIL PROTECTED] www.hub.org 1-902-542-3657 - ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
[HACKERS] Re: Link to bug webpage / Bugzilla?
Has anyone thought of using Bugzilla? (It is MySQL based, of course) but it might answer the bug database issues. (If you guys want a bug database) RedHat has a version which can use Oracle, but it seems there is a file: ftp://people.redhat.com/dkl/pgzilla-latest.tar.gz that my be interesting. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
RE: [HACKERS] RE: User locks code
I don't see problem here - just a few bytes in shmem for key. Auxiliary table would keep refcounters for keys. I think that running out of shmem *would* be a problem for such a facility. We have a hard enough time now sizing the lock table for Auxiliary table would have fixed size and so no new keys would be added if no space. I don't see problem with default 8Kb aux table, do you? system locks, even though they use fixed-size keys and the system as a whole is designed to ensure that not too many locks will be held simultaneously. (For example, SELECT FOR UPDATE doesn't try to use per-tuple locks.) Earlier in this thread, someone proposed using user locks as a substitute for SELECT FOR UPDATE. I can guarantee you that that someone will run out of shared memory before long, if the userlock table resides in shared memory. How is proposed key locking is different from user locks we have right now? Anyone can try to acquire many-many user locks. Vadim ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Link to bug webpage
On Tuesday 21 August 2001 12:47, Bruce Momjian wrote: Justin Clift [EMAIL PROTECTED] writes: After all, every bug is given an ID, so whomever fixes the bug with that ID should also mark it off. That would be pretty cool, using the mailing list archives as an _answer_ to the bug report. X-PostgreSQL-bug-ID: anyone? Or leave the bug ID number in the subject? Then the replies can be properly inserted into the database as belonging to an ID. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(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] Link to bug webpage
I disagree. Unless you are omniscient, we will only ever have a partial list. but there wasn't enough interest for someone to take on the maintenance. We need someone willing to be a kibo. Or is that too arcane a reference? -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(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] Link to bug webpage
Vince Vielhaber wrote: What who thinks of what has actually become irrelevant. The following is clear: o No tool will replace the mailing lists o The mailing lists are where discussion will be held o Many/most maintainers have no desire to update bug reports If anyone is interested, I am willing to undertake to be the link between the bugs mailing list and a bugs database. This should allow developers to continue to deal with the mailing list, just CCing a special e-mail address whenever a bug was fixed. I would then take care of finding the appropriate bug(s) in the database and marking them as fixed. There are two large, well-used bugs databases that I am aware of with somewhat different strengths: - The Debian Bug Tracking System - Bugzilla there are a gazillion others, of course, but let's just consider those two for the moment. In some ways the Debian bug tracking system is a closer fit to the way PostgreSQL currently works, since it drives into a mailing list, bug submission is via e-mail and bug control is via e-mail as well. Bugzilla is probably a closer fit in reality, since it is more focused around bugs for a single application. If Bugzilla were installed I'm sure some functionality could be added into it along the lines of the Debian BTS too. Regards, Andrew. -- _ Andrew McMillan, e-mail: Andrew @ catalyst . net . nz Catalyst IT Ltd, PO Box 10-225, Level 22, 105 The Terrace, Wellington Me: +64(21)635-694, Fax:+64(4)499-5596, Office: +64(4)499-2267xtn709 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] List response time...
Lamar Owen [EMAIL PROTECTED] writes: The best thing to do is simply to expect propagation delay. Actually, I just sent a gripe off to Marc about this. I've been noticing large and variable propagation delay for a few months now, but I just today realized that the problem is entirely local to hub.org. For example, look at the headers on your message: Received: from postgresql.org (webmail.postgresql.org [216.126.85.28]) by sss.pgh.pa.us (8.11.4/8.11.4) with ESMTP id f7LJKpY10196 for [EMAIL PROTECTED]; Tue, 21 Aug 2001 15:20:51 -0400 (EDT) Received: from postgresql.org.org (webmail.postgresql.org [216.126.85.28]) by postgresql.org (8.11.3/8.11.4) with SMTP id f7LJKpP46374; Tue, 21 Aug 2001 15:20:52 -0400 (EDT) (envelope-from [EMAIL PROTECTED]) Received: from www.wgcr.org (www.wgcr.org [206.74.232.194]) by postgresql.org (8.11.3/8.11.4) with ESMTP id f7LHxnP15711 for [EMAIL PROTECTED]; Tue, 21 Aug 2001 13:59:49 -0400 (EDT) (envelope-from [EMAIL PROTECTED]) Received: from lowen.wgcr.org (IDENT:lowen@[10.1.2.3]) by www.wgcr.org (8.9.3/8.9.3/WGCR) with SMTP id NAA25357; Tue, 21 Aug 2001 13:59:40 -0400 All the delay seems to be in transferring the message from postgresql.org to webmail.postgresql.org ... which are the same machine, or at least the same IP address. What's up with that? regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] Link to bug webpage
Lamar Owen [EMAIL PROTECTED] writes: Let's look at the guy's bulleted list. The first item he can't stand is that you can't add a column after any arbitrary column, that it goes at the end. Well, this is really clueless, as you order the columns when you SELECT or when the application presents the data. Well, I can see some value in it --- but not enough to justify the implementation pain. It certainly is pretty weak as a leadoff gripe. The second item, however, has some real meat in it. Agreed, we need better ALTER capability. As you say, it's on the TODO list. That third item, about int8. Can a clueless newbie who's heard that PostgreSQL is so great, knowing NOTHING about it, find things reasonably well in the docs? He apparently didn't get as far as looking at Table 3-1, on the first page of the user's guide chapter on datatypes. Still, improving the docs is an ever-important task. However, if it weren't too difficult to support index creation at table creation time, why NOT allow that? Do we just not _want_ to do it? We do support it, for UNIQUE indexes (see UNIQUE and PRIMARY KEY constraints). As for why not plain indexes too, the main answer is that UNIQUE constraints are SQL92 and any syntax to create indexes otherwise is not. Of course a CREATE INDEX command is not to be found in SQL92 either, but on the whole I agree with you; this is hard to read as anything except MySQL's-way-is-the-only-way partisanship. There hasn't been a lot of talk recently about adopting MySQL-isms, at least not anywhere near as much as about adopting Oracle-isms. I'd tend to treat either sort of proposal with suspicion, but we ought to be open to the idea if we are interested in attracting users of other DBMSs. Real question is, who out there is excited enough about this point to do the work? Of course, the guy didn't ask on the lists to have it put in TODO. But how would he know to ask to have something put in TODO? I see no evidence that this guy wants to learn about or contribute to Postgres development at all; he's just looking for things to rag on. (And not even doing very well at that --- I could name ten worse problems than these without taking a breath...) The TODO list is mentioned prominently on the website, for example. The last worthwhile item on this guy's list is changing ownership of a database. Well, I haven't yet had to do this: can we do this easily? It could be better. See recent Multiple Servers thread over in pg-admin, notably http://fts.postgresql.org/db/mw/msg.html?mid=1031042 (which the FTS server seems not to have linked into the thread for some reason) regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Locale by default?
Tatsuo Ishii writes: Tatsuo Ishii writes: I wouldn't object it if there is a way to disable locale support. export LC_ALL=C It's not a solution. My point is people should not be troubled by the useless feature (at least for Japanese) even if they set their locale other than C. If people set their locale to something other than C they have evidently judged that locale is not useless. Why would they set it otherwise? I don't think hiding away a feature because you think it's useless is a good idea. If people don't like it, allow them to turn it off. If there are potential problems related to the feature, document them. Face it, everything has locale support these day. PostgreSQL is one of the few packages that even has it as an option to turn it off. Users of binary packages of PostgreSQL are all invariably faced with locale features. So it's not like sudden unasked-for locale support is going to be a major shock. -- Peter Eisentraut [EMAIL PROTECTED] http://funkturm.homeip.net/~peter ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Link to bug webpage
Bruce Momjian [EMAIL PROTECTED] writes: We could try going the other way, attaching URL's to the TODO items so people can get more information about an existing bug. That might be worth doing, but I think it's mostly orthogonal to the question of a bug database. The set of problems that are (still) on the TODO list is just a small fraction of the set of bugs that someone might look in a bug database for --- anything that's already fixed in current sources is probably not going to be on TODO, if it ever got there at all (which easily-fixed problems do not). regards, tom lane ---(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] Link to bug webpage
Justin Clift [EMAIL PROTECTED] writes: After all, every bug is given an ID, so whomever fixes the bug with that ID should also mark it off. Oh? I've never seen a bug ID. Certainly the traffic in pgsql-bugs doesn't show any such thing. This isn't going to happen unless there's some fairly convenient mechanism to make it happen *in the context of responding to email on the pgsql-bugs list*. At the very least, the webform should add a link to an appropriate status-update page to the mail that it forwards to the list. That would be pretty cool, using the mailing list archives as an _answer_ to the bug report. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Link to bug webpage
On Tuesday 21 August 2001 11:11, Bruce Momjian wrote: OK, what value does a bug database have over a TODO list? The TODO list isn't just a list of bugs that need fixing. A bug database is just that -- a list of bugs in existing features. While Requests of Enhancements certainly can be accomodated through a bug database, that isn't its primary function. Bugzilla, while clunky for some things, does have some great benefits, including the ability to discuss that bug in context; attach patches, logs, stack traces, or whatnot; mark the bug's status; assign the bug to someone; as well as many other features. The TODO list as well as the mailing lists, while both great for what they do, make it all too easy to loose a bug's context, being that both lists are flat-files trying to track relational things. :-) Red Hat makes mission-critical use of bugzilla running on Oracle. See bugzilla.redhat.com. And ask the Red Hat people on these lists their opinions of bugzilla. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(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] Link to bug webpage
Bruce Momjian [EMAIL PROTECTED] writes: OK, what value does a bug database have over a TODO list? A TODO list is forward-looking. Many of the entries in a bug database would be backward-looking (already fixed). We shouldn't try to make either one serve the purpose of the other. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] Re: List response time...
Lamar Owen [EMAIL PROTECTED] writes: Mailing lists don't scale well to large numbers of subscribers. I see this delay constantly,on multiple lists. The bigger the list gets, the slower the list gets (and the more loaded the server gets, right Marc? :-)). Note that the postgresql.org mail server is still running sendmail. In my personal experience with sources.redhat.com, qmail is a much better choice to handle large mailing lists. When we switched from sendmail to qmail, mailing list delays dropped from hours, or sometimes even days, to seconds. Ian ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
[HACKERS] Re: List response time...
Tom Lane [EMAIL PROTECTED] writes: All the delay seems to be in transferring the message from postgresql.org to webmail.postgresql.org ... which are the same machine, or at least the same IP address. What's up with that? You are seeing sendmail's poorly designed queuing behaviour in action. sendmail limits itself by outgoing messages, rather than outgoing deliveries. This causes one slow delivery to hold up many fast deliveries. Ian ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] Signals blocked during auth
Hi, fortunately the problems with a malfunctioning client during the authentication don't cause the v7.2 postmaster to hang any more (thanks to Peter and Tom). The client authentication is moved into the forked off process. Now one little problem remains. If a bogus client causes a child to hang before becoming a real backend, this child is in the backend list of the postmaster, but has all signals blocked. Thus, preventing the postmaster from beeing able to shutdown. I think the correct behaviour should be to enable SIGTERM and SIGQUIT during client authentication and simply exit(0) if they occur. If so, what would be the best way to get these two signals out of the block mask? Jan -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] A fixed user id for the postgres user?
Peter Eisentraut wrote: We've had some problem reports that the current practice of initdb assigning to the postgres user the same usesysid as the user id of the Unix user running initdb has caused some clashes. ... I think the simplest fix would be to assign a fixed usesysid of 1. I was initially lukewarm about this idea, but I've just thought of a reason to like it ;-). I've been thinking a little bit about how one might recover from Really Stupid Mistakes, like deleting one's only superuser pg_shadow entry. (Let's see ... you can't make another one ... and you can't easily run pg_dump without a superuser identity ... is your database a lost cause?) I think that the only way to get around this kind of thing in extremis is to shut down the postmaster and run a standalone backend, in which you can do a CREATE USER or whatever other surgery you need to perform. Accordingly, a standalone backend should not do any permission-checking; the fact that you are able to start a backend with access to the database files should be good enough evidence that you are the superuser. However there's still a problem, if you've made this particular variety of Really Stupid Mistake: the standalone backend won't fire up. $ postgres template1 DEBUG: database system was shut down at 2001-08-21 17:56:07 EDT DEBUG: checkpoint record is at (0, 39113800) DEBUG: redo record is at (0, 39113800); undo record is at (0, 0); shutdown TRUE DEBUG: next transaction id: 8595; next oid: 262492 DEBUG: database system is ready FATAL 1: user postgres does not exist DEBUG: shutting down DEBUG: database system is shut down What I'm thinking is that if we hard-wired usesysid = 1 for the superuser, it'd be possible to arrange for standalone backends to fire up with that sysid and superuserness assumed, and not consult pg_shadow at all. Then you'd have a platform in which you could do CREATE USER. Thoughts? Next mind-bending problem: recover from DROP TABLE pg_class ;-) regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Link to bug webpage
On Tue, 21 Aug 2001, Lamar Owen wrote: I disagree. Unless you are omniscient, we will only ever have a partial list. but there wasn't enough interest for someone to take on the maintenance. We need someone willing to be a kibo. Or is that too arcane a reference? Gotta admit, I haven't heard that in a while. But I think I'm nearing a solution. Stay tuned. Vince. -- == Vince Vielhaber -- KA8CSHemail: [EMAIL PROTECTED]http://www.pop4.net 56K Nationwide Dialup from $16.00/mo at Pop4 Networking Online Campground Directoryhttp://www.camping-usa.com Online Giftshop Superstorehttp://www.cloudninegifts.com == ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Re: List response time...
On 21 Aug 2001, Ian Lance Taylor wrote: Lamar Owen [EMAIL PROTECTED] writes: Mailing lists don't scale well to large numbers of subscribers. I see this delay constantly,on multiple lists. The bigger the list gets, the slower the list gets (and the more loaded the server gets, right Marc? :-)). Note that the postgresql.org mail server is still running sendmail. In my personal experience with sources.redhat.com, qmail is a much better choice to handle large mailing lists. When we switched from sendmail to qmail, mailing list delays dropped from hours, or sometimes even days, to seconds. ooohh I've been raggin on Marc on that one for well over a year, maybe two.. I started using qmail when it was still in .7something beta and never looked back. The folks at Security Focus have moved all of the lists to ezmlm (part of qmail) and have had nothing but success... But don't tell Marc. Vince. -- == Vince Vielhaber -- KA8CSHemail: [EMAIL PROTECTED]http://www.pop4.net 56K Nationwide Dialup from $16.00/mo at Pop4 Networking Online Campground Directoryhttp://www.camping-usa.com Online Giftshop Superstorehttp://www.cloudninegifts.com == ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Re: List response time...
I've had great luck with Postfix as well. -Mitch - Original Message - From: Ian Lance Taylor [EMAIL PROTECTED] To: Lamar Owen [EMAIL PROTECTED] Cc: Serguei Mokhov [EMAIL PROTECTED]; PostgreSQL Hackers [EMAIL PROTECTED] Sent: Tuesday, August 21, 2001 4:24 PM Subject: [HACKERS] Re: List response time... Note that the postgresql.org mail server is still running sendmail. In my personal experience with sources.redhat.com, qmail is a much better choice to handle large mailing lists. When we switched from sendmail to qmail, mailing list delays dropped from hours, or sometimes even days, to seconds. Ian ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Postgresql log analyzer
Hi all, Here is a first draft generated by a log analyzer for postgres I've wrote today: http://www.samse.fr/GPL/log_report/ In all this html report there is what I'm able to extract minus the statistics. I need to know what people want to see reported to have a powerfull log analyzer, I can spend this week do do that... Peter, sorry for my poor english that what I mean is that if you don't activated the log_timestamp option we have no idea when the postmaster have been started (or at least doing a ls -la on /tmp/.s.PGSQL.5432). Other things was just question and you answer them, thanks. Regards ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] Postgresql log analyzer
Gilles DAROLD wrote: Hi all, Here is a first draft generated by a log analyzer for postgres I've wrote today: http://www.samse.fr/GPL/log_report/ In all this html report there is what I'm able to extract minus the statistics. I need to know what people want to see reported to have a powerfull log analyzer, I like what you have there so far. For my own use I would like to see the ability to turn some of these off, and also perhaps a summary page that you would click through to the more detailed reports. The 'query' page is kind of complicated too. Would it be possible to put that into a table layout as well? +---+ |select... | +++++---+ |stat|stat|stat|stat ...| | +++++---+ sort of layout. It would be nice to see an EXPLAIN on the query page, but you would want this to be an option, I guess. I imagine you could do this by getting the EXPLAIN at log analysis time if it isn't in the logs. Cheers, Andrew. -- _ Andrew McMillan, e-mail: Andrew @ catalyst . net . nz Catalyst IT Ltd, PO Box 10-225, Level 22, 105 The Terrace, Wellington Me: +64(21)635-694, Fax:+64(4)499-5596, Office: +64(4)499-2267xtn709 ---(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] Link to bug webpage
Bruce Momjian writes: Can someone point me to a bug that is _not_ on the TODO list? Just looking through pgsql-bugs of the last two weeks, the following all look reasonable. http://www.ca.postgresql.org/mhonarc/pgsql-bugs/2001-08/msg00088.html http://www.ca.postgresql.org/mhonarc/pgsql-bugs/2001-08/msg00084.html http://www.ca.postgresql.org/mhonarc/pgsql-bugs/2001-08/msg00078.html http://www.ca.postgresql.org/mhonarc/pgsql-bugs/2001-08/msg00089.html http://www.ca.postgresql.org/mhonarc/pgsql-bugs/2001-08/msg00086.html http://www.ca.postgresql.org/mhonarc/pgsql-bugs/2001-08/msg00042.html http://www.ca.postgresql.org/mhonarc/pgsql-bugs/2001-08/msg00036.html http://www.ca.postgresql.org/mhonarc/pgsql-bugs/2001-08/msg00035.html http://www.ca.postgresql.org/mhonarc/pgsql-bugs/2001-08/msg00012.html At least a couple of them I would want to have recorded somewhere. If not, what does a complete bug database do for us except list reported bugs and possible workarounds. history, searchability -- Peter Eisentraut [EMAIL PROTECTED] http://funkturm.homeip.net/~peter ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
RE: [HACKERS] Locale by default?
Zeugswetter Andreas SB SD writes: What makes you so opposed to a GUC for disabling locale support ? Nothing. It may in fact be the best solution. -- Peter Eisentraut [EMAIL PROTECTED] http://funkturm.homeip.net/~peter ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Link to bug webpage
I see no evidence that this guy wants to learn about or contribute to Postgres development at all; he's just looking for things to rag on. (And not even doing very well at that --- I could name ten worse problems than these without taking a breath...) The TODO list is mentioned prominently on the website, for example. Seeing as it was written about 7.0.X, and it took 1 year for anyone to even mention it here, meaning no one else is reading it either. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(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] Signals blocked during auth
Jan Wieck [EMAIL PROTECTED] writes: Now one little problem remains. If a bogus client causes a child to hang before becoming a real backend, this child is in the backend list of the postmaster, but has all signals blocked. Thus, preventing the postmaster from beeing able to shutdown. I think this is fairly irrelevant, because a not-yet-backend should have a fairly short timeout (a few seconds) before just shutting down anyway, so that malfunctioning clients can't cause denial of service; the particular case you mention is just one scenario. I have been intending to implement this soon if Peter didn't. OTOH, it'd be easy enough to turn on SIGTERM/SIGQUIT too, if you think there's really any value in it. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Link to bug webpage
Bruce Momjian writes: Can someone point me to a bug that is _not_ on the TODO list? Just looking through pgsql-bugs of the last two weeks, the following all look reasonable. http://www.ca.postgresql.org/mhonarc/pgsql-bugs/2001-08/msg00088.html http://www.ca.postgresql.org/mhonarc/pgsql-bugs/2001-08/msg00084.html http://www.ca.postgresql.org/mhonarc/pgsql-bugs/2001-08/msg00078.html http://www.ca.postgresql.org/mhonarc/pgsql-bugs/2001-08/msg00089.html http://www.ca.postgresql.org/mhonarc/pgsql-bugs/2001-08/msg00086.html http://www.ca.postgresql.org/mhonarc/pgsql-bugs/2001-08/msg00042.html http://www.ca.postgresql.org/mhonarc/pgsql-bugs/2001-08/msg00036.html http://www.ca.postgresql.org/mhonarc/pgsql-bugs/2001-08/msg00035.html http://www.ca.postgresql.org/mhonarc/pgsql-bugs/2001-08/msg00012.html Yes, these are all valid bugs that the TODO list didn't capture. Good point. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[HACKERS] bugs - lets call an exterminator!
In the seemingly hundreds of thousands of messages on the bug database topic I think I've come up with the following.. Needs --- easy reporting of bugs - sent to bugs list easy lookup of previous bugs summary of fix or workaround detail of fix or work around little to no intervention of developers ability of developer to add comments That should sum it up. Now some history.. Over the last couple of years we've tried a number (5 I think) of bug tracking packages. Either Marc or me or both have had to learn it, install it, get it going and the result has been the same - the maintainers don't want to update it, it's a pain in the ass to administrator, set up, etc. The current bugtool. After a bunch of these failures I asked for input on what was needed in a tool. Web input interface, ability to track the bug report, email notification to the bug list, email notification to the reporter of the bug. The current bugtool does this, however the maintainers don't want to close the reports. I'm not faulting them, they're doing their jobs by fixing the bugs and reporting them to the bugs list. Updating the database. We've had a couple of volunteers to keep the database up to date. Is it enough? I dunno, if I were to guess I'd have to look at previous experience and say probably not. But I don't want that to discourage anything or anyone. Realities PostgreSQL is growing by leaps and bounds. Ross pointed out this fact earlier today. A solution has to happen and it has to happen now. If a tool is to be adapted to this task it will be the one I'm most familiar with - the current one. Solution.. Is implementing yet another bugtool going to be the solution? Probably not. Do I want to go for number six? No. Of the ideas posted, these stick out: o Web input o Minimal staff involvement o Maximal mailing list reporting o History o Searchability Here's what I propose. The current tool has a form - we keep it. The current tool mails to the bugs list - we keep it. Rather than searching the bugs list for open bugs that may not even be open, the search tool will need to search not only the database but it needs to also search the archives. For now (until the 400+ are classified) the search should/will search the bugs mailing list rather than the database. Recruit more than two people to help update the bugs database. After the database is somewhat up to date, include it into the normal search mechanism. Now then.. The folks that actually fix things, will this suffice as a start to our shortcomingss? If not, what is missing?? If so, let me know and I'll implement this in the short term. Silence at this time is definitely NOT A GOOD THING!!! Vince. -- == Vince Vielhaber -- KA8CSHemail: [EMAIL PROTECTED]http://www.pop4.net 56K Nationwide Dialup from $16.00/mo at Pop4 Networking Online Campground Directoryhttp://www.camping-usa.com Online Giftshop Superstorehttp://www.cloudninegifts.com == ---(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] bugs - lets call an exterminator!
Vince Vielhaber [EMAIL PROTECTED] writes: Now some history.. Over the last couple of years we've tried a number (5 I think) of bug tracking packages. Either Marc or me or both have had to learn it, install it, get it going and the result has been the same - the maintainers don't want to update it, it's a pain in the ass to administrator, set up, etc. The current bugtool. After a bunch of these failures I asked for input on what was needed in a tool. Web input interface, ability to track the bug report, email notification to the bug list, email notification to the reporter of the bug. FTR, we're using bugzilla for this and it works great. We're working on porting it PostgreSQL. ftp://people.redhat.com/dkl/ should contain a recent state -- Trond Eivind Glomsrød Red Hat, Inc. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] bugs - lets call an exterminator!
At 20:08 21/08/01 -0400, Vince Vielhaber wrote: In the seemingly hundreds of thousands of messages on the bug database topic I think I've come up with the following.. Your first pass needs to have a simple mail and web based ssystem for developers to at least close bugs. The CC idea is probably fine. You might even want to put an X-header in the mail message, then for each bugs list message automatically generate a footer with a web link to close the bug, or some such - a bit like the TIPs we get all the time. This way, a developer can go to any message relating to the bug, click on the link close it. This should also send off a message to the list etc. Also, to make the jobs of the volunteers easier, it would be good for each bug details page sho show a list of bugs mailing list trafic relating to the bug, sorted by inverse date order (or, better, sub-threads). Then we can look in the most recent two or three to check the status... Philip Warner| __---_ Albatross Consulting Pty. Ltd. |/ - \ (A.B.N. 75 008 659 498) | /(@) __---_ Tel: (+61) 0500 83 82 81 | _ \ Fax: (+61) 0500 83 82 82 | ___ | Http://www.rhyme.com.au |/ \| |---- PGP key available upon request, | / and from pgp5.ai.mit.edu:11371 |/ ---(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] bugs - lets call an exterminator!
Vince Vielhaber [EMAIL PROTECTED] writes: Needs easy reporting of bugs - sent to bugs list easy lookup of previous bugs summary of fix or workaround detail of fix or work around little to no intervention of developers ability of developer to add comments That should sum it up. Check. We've had a couple of volunteers to keep the database up to date. Is it enough? I dunno, if I were to guess I'd have to look at previous experience and say probably not. AFAIR, we had *zero* people paying any attention to the state of the bug database up to now. A couple of people ought to make a big difference. Is implementing yet another bugtool going to be the solution? Probably not. Do I want to go for number six? No. If you're the man maintaining it then I'm certainly not going to tell you how to do your job. OTOH --- it does seem like a lot of people like Bugzilla. Might be worth at least a cursory look. Here's what I propose. The current tool has a form - we keep it. The current tool mails to the bugs list - we keep it. Those are both fine. How do we get feedback in the other direction, ie mailing lists to bug database? That's the $64 question in my mind at the moment. regards, tom lane ---(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] Locale by default?
If people set their locale to something other than C they have evidently judged that locale is not useless. Why would they set it otherwise? As Hiroshi pointed out, the broken thing is the LC_COLLATE, other things in the local are working. I don't think hiding away a feature because you think it's useless is a good idea. If people don't like it, allow them to turn it off. If there are potential problems related to the feature, document them. I don't object the idea letting users turn it off. I said we need a way to turn it off in the configuration/compile time. Face it, everything has locale support these day. PostgreSQL is one of the few packages that even has it as an option to turn it off. Users of binary packages of PostgreSQL are all invariably faced with locale features. So it's not like sudden unasked-for locale support is going to be a major shock. I would say it's a misunderstanding that the locale (more precisely LC_COLLATE) is usefull for *any* Language/encodings. -- Tatsuo Ishii ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
