Re: [HACKERS] Use of /etc/services?
On Fri, 7 Jun 2002, Bruce Momjian wrote: > Peter Eisentraut wrote: > > Since we now have an official entry in /etc/services, shouldn't we be able > > to make use of it, by using getservbyname() if a nonnumeric port number is > > specified? > > Is any OS actually shipping us in /etc/services? SuSE 8.0: postgresql 5432/tcp# PostgreSQL Database postqresql 5432/udp# PostgreSQL Database I'll check OpenBSD 3.1 when I'm done installing. -- Jonathan Conway [EMAIL PROTECTED] history is paling & my surge protection failed, & so I FRIED - Concrete Blonde, "Fried" ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [INTERFACES] [HACKERS] Schemas: status report, call for developers
Bruce Momjian <[EMAIL PROTECTED]> writes: > I don't have a better idea, but I am wondering how this will work. If I > create a schema with my name, does it get added to the front of my > schema schema search path automatically, Yes (unless you've futzed with the standard value of search_path). > If I want to prevent some users from creating tables in my database, do > I remove CREATE on the schema using REVOKE SCHEMA, then create a schema > for every user using the database? Well, you revoke world create access on the public schema (or maybe even delete the public schema, if you don't need it). I don't see why you'd give people their own schemas if the intent is to keep them from creating tables. 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] Use of /etc/services?
rise <[EMAIL PROTECTED]> writes: > On Fri, 7 Jun 2002, Bruce Momjian wrote: >> Is any OS actually shipping us in /etc/services? > SuSE 8.0: > postgresql5432/tcp# PostgreSQL Database > postqresql5432/udp# PostgreSQL Database Mph, complete with the typo in the UDP entry. Hang onto that, it'll be a collector's item someday ;-) regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [INTERFACES] [HACKERS] Schemas: status report, call for developers
Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: > > I don't have a better idea, but I am wondering how this will work. If I > > create a schema with my name, does it get added to the front of my > > schema schema search path automatically, > > Yes (unless you've futzed with the standard value of search_path). > > > If I want to prevent some users from creating tables in my database, do > > I remove CREATE on the schema using REVOKE SCHEMA, then create a schema > > for every user using the database? > > Well, you revoke world create access on the public schema (or maybe even > delete the public schema, if you don't need it). I don't see why you'd > give people their own schemas if the intent is to keep them from > creating tables. No, I was saying you would have to create schemas for the people who you _want_ to be able to create tables. With the old NOCREATE patch, you could just remove create permission from a user. With schemas, you have to remove all permission for table creation, then grant it to those you want by creating schemas for them. This is similar to handling of Unix permissions. If you want to restrict access to a file or directory, you remove public permission, and add group permission, then add the people who you want access to that group. There are no _negative_ permissions, as there are no negative permissions in the unix file system. I just wanted to be clear that restricting access will be multi-step process. If I remove public create access to public, can the super user or db owner still create tables? -- 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] Use of /etc/services?
Tom Lane wrote: > rise <[EMAIL PROTECTED]> writes: > > On Fri, 7 Jun 2002, Bruce Momjian wrote: > >> Is any OS actually shipping us in /etc/services? > > > SuSE 8.0: > > > postgresql 5432/tcp# PostgreSQL Database > > postqresql 5432/udp# PostgreSQL Database > > Mph, complete with the typo in the UDP entry. Hang onto that, it'll > be a collector's item someday ;-) Isn't Suse centralizing development for the new UnitedLinux2? Guess Red Hat doesn't have much to worry about. ;-) -- 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] Roadmap for a Win32 port
Peter Eisentraut <[EMAIL PROTECTED]> writes: >> Also, it seems Win32 doesn't need these scripts, except initdb. > The utility of these programs is independent of the platform. If we think > pg_dumpall is not useful, then let's remove it. I have been seriously considering converting pg_dumpall to C anyway, because it's already *very* messy, and I don't see any reasonable way to make it support dumping per-database and per-user config settings. (Do you really want to try to parse array values in a shell script?) (I'd actually consider making pg_dumpall a part of the pg_dump executable; then it could invoke pg_dump as a subroutine call...) If Peter's got the time/energy to convert 'em all, I'm for it. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Question whether this is a known problem in 7.1.2
Rachit Siamwalla <[EMAIL PROTECTED]> writes: > There are 2 items that match the criteria, and you do a LIMIT 2, it > scans the whole table as well. Limit 1 returns quickly. Basically it > seems like postgres is looking for one more item than it needs to. This is not a bug; or at least it's not something I'm prepared to break other things to change. If you can figure out a way to change nodeLimit.c to not get confused about change-of-fetch-direction without the extra fetch, then send a patch. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Roadmap for a Win32 port
Tom Lane wrote: > Peter Eisentraut <[EMAIL PROTECTED]> writes: > >> Also, it seems Win32 doesn't need these scripts, except initdb. > > > The utility of these programs is independent of the platform. If we think > > pg_dumpall is not useful, then let's remove it. > > I have been seriously considering converting pg_dumpall to C anyway, > because it's already *very* messy, and I don't see any reasonable > way to make it support dumping per-database and per-user config > settings. (Do you really want to try to parse array values in a > shell script?) > > (I'd actually consider making pg_dumpall a part of the pg_dump > executable; then it could invoke pg_dump as a subroutine call...) > > If Peter's got the time/energy to convert 'em all, I'm for it. Yea, shame it will now take 15 lines of C code to do what we could do in 1 line of shell script but I don't see any other option. -- 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://archives.postgresql.org
Re: [INTERFACES] [HACKERS] Schemas: status report, call for developers
Bruce Momjian <[EMAIL PROTECTED]> writes: > If I remove public create access to public, can the super user or db > owner still create tables? Superusers can always do whatever they want. The DB owner (assume he's not a superuser) has no special privileges w.r.t. the public schema at the moment. We could perhaps put in a kluge to change this, but it would definitely be a kluge --- I don't see any clean way to make the behavior different. One possible approach would be for a superuser to change the ownership of public to be the DB owner. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Roadmap for a Win32 port
Bruce Momjian <[EMAIL PROTECTED]> writes: > Yea, shame it will now take 15 lines of C code to do what we could do in > 1 line of shell script but I don't see any other option. In places we are using 15 lines of shell to do what would take 1 line in C ;-). Yes, it'll probably be bigger overall, but I think you are overstating the penalty. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Alternatives to SQL ...
The world rejoiced as [EMAIL PROTECTED] (Martijn van Oosterhout) wrote: > On Fri, May 24, 2002 at 12:43:36PM -0500, Gunther Schadow wrote: >> - Sending a parse tree in XML for processing by the optimizer. >>This circumvents the SQL language and avoids the kinds of >>syntactic ideosyncrasies of SQL (e.g., where you put commas.) >>This is fairly trivial, but of course the question is, would it >>be worth it? X-Mailer: mh-e 6.1; nmh 1.0.4+dev; Emacs 21.4 > I don't know if you can design something in XML that is expressive > and simple enough to compete with SQL. SQL is a simple language, why > replace it with something unless it is demonstrably better. SQL is good at providing "linear" queries; queries that indicate some "linear" relationship between elements. It is not so good at representing hierarchical relationships, which is what XML is about. The SQL: SELECT FIELDS FROM TABLE provides you with a linear list. SQL isn't _nearly_ as nice at representing things that are naturally expressed as trees. It's pretty easy to have a DB schema where you essentially have to submit an SQL query for every level of the tree. And I am not ignoring JOIN here; that adds _some_ ability to join together levels of trees, but not an unlimited ability. The XML model fundamentally involves a hierarchy, and the 'query method' involves passing in a function that reshapes that hierarchy. I think there would be considerable value to that. It certainly needs to be thought about before it is implemented, but it's worth thinking about, to be sure. -- (reverse (concatenate 'string "gro.gultn@" "enworbbc")) http://www.ntlug.org/~cbbrowne/multiplexor.html "It is easier to move a problem around (for example, by moving the problem to a different part of the overall network architecture) than it is to solve it." -- RFC 1925 ---(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] Use of /etc/services?
On Sat, 8 Jun 2002, Peter Eisentraut wrote: > This is inconsistent with the official IANA assignment which reads Thanks. I'll update my services file and check all those I come into contact with. I'll check if a new install if Redhat 7.3 has the correct entries this weekend. > postgresql 5432/tcp# PostgreSQL Database > postqresql 5432/udp# PostgreSQL Database > # Tom Lane <[EMAIL PROTECTED]> > > (The spelling might have been fixed by now.) It is corrected. > You should probably file a bug report for your OS. Interesting. I've never done this before. Most of the problems like this I see after someone else has repored them. Maybe I'll get my 5 minutes of fame. Cheers, Rod -- Please don't tell my mother I'm a System Administrator. She thinks I play piano in a bordello. ---(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] Roadmap for a Win32 port
Peter Eisentraut wrote: > Bruce Momjian writes: > > > I know I have discouraged it because I think shell script language has a > > good toolset for those applications. I have fixed all the spacing > > issues. > > My point is that it is not, for the reasons that I listed. Handling > spaces is a small part of one of the several problems, there are problems > with newlines, tabs, commas, slashes, quotes -- everytime you call sed or > read you lose one character. > > > What language where you thinking of using? C? > > Yes, that way we can share code (pg_dumpall<->pg_dump, initdb<->postgres), > use the established internationalization facilities, and use libpq > directly in create* and drop*. > > > Also, it seems Win32 doesn't need these scripts, except initdb. > > The utility of these programs is independent of the platform. If we think > pg_dumpall is not useful, then let's remove it. I think the first two targets for C-ification would be pg_dumpall and initdb. The others have SQL equivalents. Maybe pg_ctl too. -- 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://archives.postgresql.org
Re: [HACKERS] Per tuple overhead, cmin, cmax, OID
Tom Lane wrote: > Uh guys ... what I *said* was: > > > I think we are planning to go beta in late summer (end of August, say). > > Probably in July we'll start pressing people to finish up any major > > development items, or admit that they won't happen for 7.3. > > By which I meant that in July we should start hounding anyone who's got > major unfinished work. (Like, say, me, if the schema changes are still > incomplete then.) Not that we won't accept the work when it gets here, > just that that'll be the time to start demanding closure on big 7.3 > changes. OK. > And yes, I *would* be pretty upset with the idea of applying major > patches in the last weeks of August, if they are changes that pop up > out-of-the-blue at that time. If it's finishing up work that the > community has already approved, that's a different scenario. But big, > poorly-reviewed feature additions right before beta are exactly my idea > of how to mess up that reputation for stability that Marc was touting... Yes, but there is a downside to this. We have trouble enough figuring out if a patch is a "feature" or "bug fix" during beta. How are people going to decide if a feature is "big" or not to work on during August? It has a paralyzing effect on our developers. Now, I don't want to apply a partially-implemented feature in the last week of August, but I don't want to slow things down during August, because the last time we did this we were all looking at each other waiting for beta, and nothing was getting done. This is the paralyzing effect I want to avoid. We have beta for testing. That's were our reliability comes from too. And last beta, we did almost nothing because we had shut down development so early, and it dragged because there _wasn't_ a clear line between development time and beta. So, I we should: Warn people in July that beta is September 1 and all features have to be complete by then, or they get ripped out. Reject non-complete patches during August, meaning accepted patches in August have to be fully functional features; no partial patches and I will work on the rest later. Vote on any patches where there is disagreement. So, in summary, for me, August patches have to be 100% complete. That takes the guess work out of the deadline. There isn't the question of whether we will accept such a feature or not. The burden is on the developer to provide a 100% complete patch. -- 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] Project scheduling issues (was Re: Per tuple overhead, cmin, cmax, OID)
Bruce Momjian <[EMAIL PROTECTED]> writes: > Now, I don't want to apply a partially-implemented feature in the last > week of August, but I don't want to slow things down during August, > because the last time we did this we were all looking at each other > waiting for beta, and nothing was getting done. This is the paralyzing > effect I want to avoid. Well, my take on it is that the reason beta was delayed the last two go-rounds was that we allowed major work to be committed in an incomplete state, and then we were stuck waiting for those people to finish. (The fact that the people in question were core members didn't improve my opinion of the situation ;-)) I'd like to stop making that mistake. > So, I we should: > Warn people in July that beta is September 1 and all features > have to be complete by then, or they get ripped out. > Reject non-complete patches during August, meaning accepted > patches in August have to be fully functional features; no > partial patches and I will work on the rest later. I thought that was more or less the same thing I was proposing... regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Timestamp/Interval proposals: Part 2
Thomas, > Please define "a full set of operators". Or do the subsequent > proposals > defining new behaviors and some operations constitute that list? + - / * < > = and, if appropriate, % Where support is lacking is * and / Don't get me wrong. PostgreSQL has the best implementation of date/time/interval handling in any database I use. It's just that there are a few limitations and wierdnesses left, and I'd really like to see them ironed out so that we can call our impelmentation "near perfect". Also, so I can stop coding workarounds into my database apps. > You are overstating the problem imho, but there is a problem for some > users. SQL9x avoids the issue by defining *only* constant offsets for > time zones. That doesn't work in the real world :/ > > We would expand the storage size by at least 4 bytes to accomodate > the > "qualitative day" information. Currently takes 12 bytes, and will > take > 16 or more. We will need to check for overflows during date/time > math, > we will need some heuristics for conversions between hours and days > during calculations, and some users will need to cope with the > changed > behavior. Operations like math and comparisons will be more expensive > (though may not be a hugely noticable effect). I can see why you've put off doing it. At a basic level, though, current behaviour is counter-intuitive, so we'll need to do it someday. > Oh. Didn't know it wasn't already there. Not in 7.2.1. And if you don't know about it, probably not in 7.3 either. > > Alternative #1: Treat Interval Increments as Atomic, and Round > > Yuck (imho of course ;) Hey, I did ask for an opinion. > > Alternative #2: Tie Intervals to a Specific Timestamp > > Double yuck. You already have this capability by your choice of > schema; > intervals are intervals and timestamps are timestamps. The behaviors > you > discuss above (both current and possible) handle this. Hmmm? How much is '1 month' / '4 days' then? The current implementation does not support the / and * operators; that is, they are supported for some type combos, but not for others, and the results are inconsistent and sometimes confusing. > Bad example, and I'm not following your argument here. PostgreSQL > supports *many* time zones (Peter E. has said "too many") and any > change > for the Arizona example will be at odds with how dates and times are > expected to be handled in, uh, Arizona. They use Mountain Standard > Time > (MST), except for years when they didn't, and are covered by > specifying > "MST" on input and "SET TIME ZONE 'America/Phoenix'" (and perhaps > others > too; it seems that "MST6" gives me consistant behavior on my Linux > box). Actually, the real problems I have encountered with time zones would be solved mostly by adding the 'WEEKS TO DAYS' subtype above. Currently I'm forced to use TIMESTAMP WITHOUT TIMEZONE in order to avoid the wierd one-hour shifts in my calendaring app. > I can't imagine that you are not finding a workable solution with the > current capabilities. That said, we are considering adopting the > historic zinc package to support time zones within PostgreSQL (sounds > like you might be doing some of the development ;). And for time zone > lookup (not supported in the zinc API) it *would* be nice to move to > a > DBMS table-based implementation, rather than the hardcoded tables we > have now. They may have been good enough for the last 12 years, but > certainly lookup stuff seems like it should be in a database table, > eh? Yeah. I'd love to have somebody explain this to me. I noticed when zinc was mentioned, but I don't know *what* it is. Care to send me a link? __AGLIO DATABASE SOLUTIONS___ Josh Berkus Complete information technology [EMAIL PROTECTED] and data management solutions (415) 565-7293 for law firms, small businessesfax 621-2533 and non-profit organizations. San Francisco ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Per tuple overhead, cmin, cmax, OID
On Sat, 8 Jun 2002, Bruce Momjian wrote: > Yes, but there is a downside to this. We have trouble enough figuring > out if a patch is a "feature" or "bug fix" during beta. How are people > going to decide if a feature is "big" or not to work on during August? > It has a paralyzing effect on our developers. How is this any different then our other releases? I think you've totally lost me as to where the problem is ... reading your above, you are suggesting that ppl don't work on big projects during the month of August, since it might not get in for the release? We've never advocated that before, nor do I believe we should at this point ... in fact, I think its about time we start dealing with beta using the tools that we have available ... Beta starts, we branch out a -STABLE vs -DEVELOPMENT branch in CVS ... we release a beta1 and deal with bug releases as they come in, followed by a beta2 until we are ready for release ... I think everyone is old enough now to be able to decide whatfixed have gone into -STABLE that should be reflected in -DEVELOPMENT, no? Our mistake last release wasn't how long beta lasted, but how long we stalled development ... ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] revised sample SRF C function; proposed SRF API
Joe Conway <[EMAIL PROTECTED]> writes: > The question is how to best bootstrap this new function. In order to > create the pg_proc entry I need the return type oid. If I understand > correctly, in order to get a composite return type, with a known oid, I > would need to create a bootstrapped relation and the corresponding > bootstrapped pg_type entry. Well, we're not doing that; and I see no good reason to make the thing be a builtin function at all. Since it's just an example, it can very well be a contrib item with a creation script. Probably *should* be, in fact, because dynamically created functions are what other people are going to be building; an example of how to do it as a builtin function isn't as helpful. Further down the road it may be that we'll get around to allowing freestanding composite types (ie, ones with no associated table). That would make it less painful to have builtin functions returning tuples --- though not by a lot, since you'd still have to manufacture pg_type and pg_attribute rows for 'em by hand. I'm not in a hurry to do that in any case, because of the extent of restructuring of pg_class, pg_type, and pg_attribute that would be needed. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Per tuple overhead, cmin, cmax, OID
Marc G. Fournier wrote: > On Sat, 8 Jun 2002, Bruce Momjian wrote: > > > Yes, but there is a downside to this. We have trouble enough figuring > > out if a patch is a "feature" or "bug fix" during beta. How are people > > going to decide if a feature is "big" or not to work on during August? > > It has a paralyzing effect on our developers. > > How is this any different then our other releases? I think you've totally > lost me as to where the problem is ... reading your above, you are > suggesting that ppl don't work on big projects during the month of August, > since it might not get in for the release? We've never advocated that > before, nor do I believe we should at this point ... in fact, I think its > about time we start dealing with beta using the tools that we have > available ... In previous releases, we had this "it is too close to beta to add feature X" mentality, and I see Tom reiterating that in his email. It is the idea were are supposed to go into beta with a bug-free release that bother me. August is prime time for open-source development. Many countries have holidays, and business is slow, so people have time to work projects. Let's use that time to improve PostgreSQL, and leave beta for fixing. > Beta starts, we branch out a -STABLE vs -DEVELOPMENT branch in CVS ... we > release a beta1 and deal with bug releases as they come in, followed by a > beta2 until we are ready for release ... I think everyone is old enough > now to be able to decide whatfixed have gone into -STABLE that should be > reflected in -DEVELOPMENT, no? Our mistake last release wasn't how long > beta lasted, but how long we stalled development ... Agreed. Let's split sometime during beta as soon as we are ready to work on 7.4. Sooner and we just double-patch for no purpose, later and we stall development. -- 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
Default privileges for new databases (was Re: [HACKERS] Can't import large objects in most recent cvs)
Ron Snyder <[EMAIL PROTECTED]> writes: > May 31 16:11:50 vault pgcvs[2135]: [91] LOG: query: Create Temporary Table > pg_dump_blob_xref(oldOid pg_catalog.oid, newOid pg_catalog.oid); > May 31 16:11:50 vault pgcvs[2135]: [93] ERROR: quickview: not authorized to > create temp tables > My theory is that I'm getting this last message (not authorized to create > temp tables) because the permissions have been tightened down. Yeah. Right at the moment, new databases default to only-db-owner-has- any-rights, which means that others cannot create schemas or temp tables in that database (unless they're superusers). I'm of the opinion that this is a bad default, but was waiting to see if anyone complained before starting a discussion about it. Probably we should have temp table creation allowed to all by default. I'm not convinced that that's a good idea for schema-creation privilege though. Related issues: what should initdb set as the permissions for template1? Would it make sense for newly created databases to copy their permission settings from the template database? (Probably not, since the owner is likely to be different.) What about copying those per-database config settings Peter just invented? Comments anyone? 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] [Fwd: Bug#149056: postgresql: should not try in a busy loop when allocating resources]
Oliver Elphick <[EMAIL PROTECTED]> forwards: > When trying to create a semaphore Postgresql 7.2.1-3 will try 400,000 times= > per > second if it has problems. AFAICS it will try *once* and abort if it fails. Can you provide a reproducible test case for the above behavior? regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Project scheduling issues (was Re: Per tuple overhead,
Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: > > Now, I don't want to apply a partially-implemented feature in the last > > week of August, but I don't want to slow things down during August, > > because the last time we did this we were all looking at each other > > waiting for beta, and nothing was getting done. This is the paralyzing > > effect I want to avoid. > > Well, my take on it is that the reason beta was delayed the last two > go-rounds was that we allowed major work to be committed in an > incomplete state, and then we were stuck waiting for those people to > finish. (The fact that the people in question were core members didn't > improve my opinion of the situation ;-)) I'd like to stop making that > mistake. I am going to recommend disabling features that people can't fix in a timely manner during beta. Sounds harsh, but we can't have the whole project waiting on one person to have a free weekend. If they can generate a patch, we can re-enable the feature, but we need to get some discipline for everyone's benefit. I don't think any of us wants to be embarrassed by the beta duration again. > > So, I we should: > > Warn people in July that beta is September 1 and all features > > have to be complete by then, or they get ripped out. > > Reject non-complete patches during August, meaning accepted > > patches in August have to be fully functional features; no > > partial patches and I will work on the rest later. > > I thought that was more or less the same thing I was proposing... This is the text I objected to: Tom Lane wrote: > And yes, I *would* be pretty upset with the idea of applying major > patches in the last weeks of August, if they are changes that pop up > out-of-the-blue at that time. If it's finishing up work that the > community has already approved, that's a different scenario. But big, > poorly-reviewed feature additions right before beta are exactly my idea > of how to mess up that reputation for stability that Marc was touting... It emphasizes August as primarily finish-up time. And there is that "pre-approved" part I don't like. Feature has to be done by the end of August, doesn't matter whether it is approved or not. If someone wants to start and complete a feature during August, "go ahead" is my moto. -- 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] [Fwd: Bug#149056: postgresql: should not try in a busy
Tom Lane wrote: > Oliver Elphick <[EMAIL PROTECTED]> forwards: > > When trying to create a semaphore Postgresql 7.2.1-3 will try 400,000 times= > > per > > second if it has problems. > > AFAICS it will try *once* and abort if it fails. Can you provide a > reproducible test case for the above behavior? I assume he meant tries to grab a semaphore 400,000 times, but I may be wrong. -- 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] [Fwd: Bug#149056: postgresql: should not try in a busy
Bruce Momjian <[EMAIL PROTECTED]> writes: > I assume he meant tries to grab a semaphore 400,000 times, but I may > be wrong. I don't believe that would happen either ... 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] revised sample SRF C function; proposed SRF API
Tom Lane wrote: > Well, we're not doing that; and I see no good reason to make the thing > be a builtin function at all. Since it's just an example, it can very > well be a contrib item with a creation script. Probably *should* be, > in fact, because dynamically created functions are what other people are > going to be building; an example of how to do it as a builtin function > isn't as helpful. True enough, although I could always create another example for contrib. Returning GUC variable "SHOW ALL" results as a query result has been discussed before, and I thought there was agreement that it was a desirable backend feature. Is the approach in my patch still too ugly to allow a builtin SRF (set the function return type to 0 in pg_proc.h, create a view and fix the pg_proc entry during initdb)? If so, I'll rework the patch into two patches: one for the composite/set returning function api, and one for show_all_vars() as a contrib/SRF example. If not, I'll just come up with another function for contrib to serve as a reference implementation for others. Thanks, Joe ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[Fwd: Re: [HACKERS] [Fwd: Bug#149056: postgresql: should not try ina busy loop when allocating resources]]
Russell, can you provide a test case, or at least explain the circumstances, please. Please maintain the Cc list. -Forwarded Message- From: Tom Lane <[EMAIL PROTECTED]> To: Oliver Elphick <[EMAIL PROTECTED]> Cc: [EMAIL PROTECTED] Subject: Re: [HACKERS] [Fwd: Bug#149056: postgresql: should not try in a busy loop when allocating resources] Date: 08 Jun 2002 22:03:33 -0400 Oliver Elphick <[EMAIL PROTECTED]> forwards: > When trying to create a semaphore Postgresql 7.2.1-3 will try 400,000 times= > per > second if it has problems. AFAICS it will try *once* and abort if it fails. Can you provide a reproducible test case for the above behavior? regards, tom lane -- Oliver Elphick[EMAIL PROTECTED] Isle of Wight http://www.lfix.co.uk/oliver GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C "Verily, verily, I say unto you, He that heareth my word, and believeth on him that sent me, hath everlasting life, and shall not come into condemnation; but is passed from death unto life." John 5:24 signature.asc Description: This is a digitally signed message part
Re: [HACKERS] Per tuple overhead, cmin, cmax, OID
On Sat, 8 Jun 2002, Bruce Momjian wrote: > It is the idea were are supposed to go into beta with a bug-free release > that bother me. But its you that's always tried to advocate that ... no? If not, then I am confused, cause I know *I've* never ... to me, switching to beta mode has always been the switch from 'add features' to 'fix the bugss to release' ... > Agreed. Let's split sometime during beta as soon as we are ready to > work on 7.4. Sooner and we just double-patch for no purpose, later and > we stall development. No, let's split *at* beta ... I imagine there are several ppl out there that have alot of work they wish to do, and sitting around twiddling their thumbs waiting for someone to *maybe* report a bug in their area/code is a waste of everyone's time ... not to mention a delay in being ready to release the next version ... Hell, each 'beta period' we've done so far has caused that ... where we get in patches and changes that aren't appropriate for beta and they get sat on until after its been released ... then you risk the fun of merging in conflicting changes, so the patch that was perfect when it was submitted has to be redone because someone else's patch changed enough to the code that it doesn't apply cleanly ... Its not like it was years ago when there were a couple of us in the code ... there are enough developers out there now (and growing) that 'stalling' things isn't fair to them (or, in some cases, the companies that are paying them to develop features) ... We have the tools to do this, its time to start using them the way they were meant to be used ... ---(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] Project scheduling issues (was Re: Per tuple overhead,
On Sat, 8 Jun 2002, Bruce Momjian wrote: > Tom Lane wrote: > > Bruce Momjian <[EMAIL PROTECTED]> writes: > > > Now, I don't want to apply a partially-implemented feature in the last > > > week of August, but I don't want to slow things down during August, > > > because the last time we did this we were all looking at each other > > > waiting for beta, and nothing was getting done. This is the paralyzing > > > effect I want to avoid. > > > > Well, my take on it is that the reason beta was delayed the last two > > go-rounds was that we allowed major work to be committed in an > > incomplete state, and then we were stuck waiting for those people to > > finish. (The fact that the people in question were core members didn't > > improve my opinion of the situation ;-)) I'd like to stop making that > > mistake. > > I am going to recommend disabling features that people can't fix in a > timely manner during beta. Sounds harsh, but we can't have the whole > project waiting on one person to have a free weekend. If they can > generate a patch, we can re-enable the feature, but we need to get some > discipline for everyone's benefit. I don't think any of us wants to be > embarrassed by the beta duration again. I wasn't embarrassed by it ... when I talk to ppl asking about QA on PostgreSQL, I quite proudly point out that we'd rather delay then release something we aren't confident about *shrug* > It emphasizes August as primarily finish-up time. And there is that > "pre-approved" part I don't like. Feature has to be done by the end of > August, doesn't matter whether it is approved or not. If someone wants > to start and complete a feature during August, "go ahead" is my moto. Personally ... I'm really curious as to why you are even trying to 'formalize' stuff that has been done for years now ... end of August rolls around and someone submits a feature patch, we do as we've always done ... we discuss its merits, and its risk factor ... if it presents too high a risk, it gets put on the 'patch stack' for the next release ... or do you think our judgement in such matters is such that we have to formalize/set in stone this common sense stuff beforehand? I *really* wish ppl would stop harping on the length of the last beta cycle ... I will always rather delay a release due to an *known* outstanding bug, especially one that just needs a little bit more time to work out, then to release software "on time" ala Microsoft ... Hell, you are trying to set in stone when beta starts (end of august) ... but with some of the massive changes that we tend to see over the course of a development project, for all we know, Tom will be 90% finished something and only need another week to get it complete ... personally, he's one of many whose code I wouldn't question, so giving another week to get it done and in, IMHO, is perfectly acceptable ... but, for what you are trying to get set in stone, it wasn't finished by Sept 1st, so we'll throw it all out until the next release ... Right now, Sept 1st is the "preferred date to go beta" ... when Sept 1st rolls around, like we've always done in the past, we will review that and if we need to delay a little, we will *shrug* ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Project scheduling issues (was Re: Per tuple overhead, cmin, cmax, OID)
"Marc G. Fournier" <[EMAIL PROTECTED]> writes: > I *really* wish ppl would stop harping on the length of the last beta > cycle ... I will always rather delay a release due to an *known* > outstanding bug, especially one that just needs a little bit more time to > work out, then to release software "on time" ala Microsoft ... I don't think that's at issue here. No one was suggesting that we'd force an *end* to beta cycle because of schedule issues. We ship when we're satisfied and not before. I'm saying that I want to try to *start* the beta test period on-time, rather than letting the almost-beta state drag on for months --- which we did in each of the last two cycles. Development time is productive, and beta-test time is productive, but we're-trying-to-start-beta time is not very productive ... regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
