[HACKERS] BTW, if anyone wants to work on it...
We've had a couple of cases recently where we had to advise DBAs to make manual changes in the system catalogs --- see for instance the 7.4.2 release notes or http://archives.postgresql.org/pgsql-announce/2005-05/msg1.php It'd be nicer if this sort of thing could be handled automatically by a software update. There are good reasons why it's not trivial, but having been burnt twice in recent memory, I'm starting to think it'd be worth setting up a mechanism to handle such changes automatically. Anyone up for working on it? 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: [pgsql-advocacy] [HACKERS] Increased company involvement
Bruce Momjian wrote: (Funny, no one says I have too much power. I will have to look into how to get some someday.) :-) I think you have power, too. :-) You have commited many patches that some other commiters didn't like that much and would rather not have applied themselves. All with some consensus from the community, of course. The reason, IMHO, that Tom is seen as someone with more power than others, is because of his intimate knowledge of postgresql and software design in general. Most of his proposals are very welcome to the community and nobody would be against those. And if there are objections, Tom will usually listen to valid criticism and adapt his work. Not all core members or regular patch submitters have agreed with all changes in the past, not even within this "in"-group. There are different opinions and it's not one who always "wins". I believe there is quite a balance. For many changes and patches proposed, most of the rejections I have seen were based on lack of knowledge of either postgresql design or philosophy or bad software design in general. Of course its rather the "in"-group who defined the postgresql design and philosophy in the first place, but well, it is because of them that postgresql exists as what it is. Most of the hassles can be avoided by speaking up on hackers first and convince some one with good postgresql know-how to help you get your work on track. Best Regards, Michael Paesold ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
> > Another example is the recent patch to check if there are orphaned file > system files. That was submitted, Tom had questions, I posted why I > thought it was valid, and the patch is going in today. Anyone has the > ability to argue their point and try to sway the community, and any > member has the right to request a vote on a specific issue. > I know so maintainig of PostgreSQL isn't easy. And it's normal so everybody wont to see commit of your patch. The comunication with core developers is best, but some times I have opinion so some patches are lost - for example my little patch SQLSTATE, .. I remeber situation one year ago with named params of plpgsql function. Patch waited half of year. I don't wont to be negative :-)). PostgreSQL did big progress. Really. And last modification of plpgsql helped my in work. But its human natural. I looking for others nows. I am expectant for 2PC, hiearch queries, and ... PostgreSQL isn't only sw for me, it's more like idol :-) Best Regards, Pavel Stehule ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
Marc G. Fournier wrote: Agreed ... if someone can make the project, I can move the CVS files over ... does anyone know who is currently maintaining it though? A little research would reveal: % head contrib/dbmirror/README.dbmirror DBMirror - PostgreSQL Database Mirroring === DBMirror is a database mirroring system developed for the PostgreSQL database Written and maintained by Steven Singer([EMAIL PROTECTED]) (ssinger does submit patches for it on a reasonably regular basis.) -Neil ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] pg_locks needs a facelift
"Merlin Moncure" <[EMAIL PROTECTED]> writes: > Yep. Actually, the biggest part of this was figuring out what to do > about the pg_locks view. Since that's basically decided, all that > remains is to decide what if anything to do about the > max_locks_per_transaction GUC variable. User locks at the very least > are extra-transactional so this could perhaps be renamed. I'm not in favor of renaming the variable unless a really significantly more descriptive name is proposed. I can't think of any short names that are markedly better than max_locks_per_transaction. To me the main shortcoming of that name has nothing to do with user locks: it's that it suggests that we enforce a hard limit on each transaction individually, when in fact we do no such thing (the limit is on the total number of locks in existence, not how many are owned by whom). > FWIW, I'm a huge fan of the current behavior which is to drop > transactions when running out of lock-space. I can't quite tell if that was supposed to have a smiley or not ... regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] SPI bug.
Thomas Hallgren wrote: Tom Lane wrote: Furthermore, we have never promised ABI-level compatibility across versions inside the backend, and we are quite unlikely to make such a promise in the foreseeable future. I know that no promises has been made but PostgreSQL is improved every day and this would be a very easy promise to make. Binary compatibility of backend APIs is by no means a "very easy promise to make," nor would it be a good idea in any case. Also, the interpretation of the definition vary between compiler vendors. On Windows Itanium, the int is 32 bit. On Unix it's 64. `int' is 32 bit on most modern platforms I can think of. Perhaps you're thinking of `long', which is indeed 64-bit on many 64-bit Unixen but 32-bit on 64-bit Windows (BTW, this likely means that Postgres is completely broken on 64-bit Windows: sizeof(Datum) == sizeof(unsigned long) == 4, sizeof(void *) == 8). The 1998 revision of C declares the following types for a good reason: int8_t , int16_t, int32_t int64_t, uint8_t, uint16_t, uint32_t, uint64_t. We don't currently depend on C99, and not all platforms have a 64-bit datatype. In any case, I'm still unconvinced that using `int' and `long' in backend APIs is a problem. -Neil ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [pgsql-advocacy] [HACKERS] Decision Process WAS: Increased company involvement
Robert Treat said: >> * Engage the community by participating in discussions and patch >> reviews - your credibility as a contributor depends on your >> willingness to contribute to the community in non-coding >> ways as well > > Actually I think Bruces blurb is good for the general FAQ, and this > would be good for the Developer FAQs > I nat happy avout that last point - personally, I value most highly the views of those who contribute code or similar and least highly the views of those whose principal contribution is opinions. cheers andrew ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [pgsql-advocacy] [HACKERS] Decision Process WAS: Increased company involvement
On Monday 02 May 2005 17:32, Dave Held wrote:
> > -Original Message-
> > From: Bruce Momjian [mailto:[EMAIL PROTECTED]
> > Sent: Monday, May 02, 2005 3:33 PM
> > To: Dave Held
> > Cc: PostgreSQL advocacy; PostgreSQL-development
> > Subject: Re: [pgsql-advocacy] [HACKERS] Decision Process WAS:
> > Increased
> > company involvement
> >
> > [...]
> > Here is a new FAQ entry:
> >
> > 1.13) Who controls PostgreSQL?
> >
> > If you are looking for a PostgreSQL gatekeeper,
> > central committee, or controlling company, give up, because
> > none exists. We do have a core committee and CVS committers,
> > but these groups are more for administrative purposes then
> > control. The project is directed by the open community of
> > developers and users of PostgreSQL. Everyone is welcome to
> > subscribe and take part in the discussions. (See the
> > http://www.postgresql.org/docs/faqs.FAQ_DEV.html";>
> > Developer's FAQ for information on how to get
> > involved in PostgreSQL development.)
> >
> > Adjustments?
>
> "...are more for administrative purposes [then->than] control..."
>
> Because PostgreSQL is a monolithic product, all of its features
> must work together in tight harmony. It is in the interests of
> the PostgreSQL community that new features be integrated in a way
> that preserves this harmony. Thus, new feature proposals are
> scrutinized and debated by the community to ensure that changes
> have sufficient technical merit. Be prepared to defend your
> proposal, and don't assume that a privately developed contribution
> will automatically be accepted by the PostgreSQL community. To
> maximize the chance of success in proposing a change, consider
> these suggestions:
>
> * Propose your change/feature publicly - OSS is about community,
> and a collection of contributors working independently without
> communication is not a community; this avoids duplication of
> effort and promotes collaboration/cooperation among parties
> that have a common interest
> * Research your proposal to see if it has already been discussed
> on the mailing list
> * Research your proposed solution to make sure it is the best of
> breed - database technology is a very active subject of
> academic research, and it is possible, if not likely, that
> someone has written a paper on the topic
> * Engage the community by participating in discussions and patch
> reviews - your credibility as a contributor depends on your
> willingness to contribute to the community in non-coding
> ways as well
>
>
> I realize that this runs a bit far afield from the original
> question of "Who controls PostgreSQL?", but I think it addresses
> the points that someone who asks this question is likely to
> want to know. It also tackles the contribution question from
> a higher level than the dev-faq.
Actually I think Bruces blurb is good for the general FAQ, and this would be
good for the Developer FAQs
--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(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] Heads up: impending 8.0, 7.4, 7.3 releases
Tom Lane wrote: As you probably already read on pgsql-announce, we are looking to release updates in the 7.3 and later branches shortly, due to some recently identified security issues. (BTW, thanks to [EMAIL PROTECTED] for reporting the conversion-function problem.) There's not a definite time set yet, but it'll be in the next couple of days. Anyone have any last-minute fixes they want to get into those releases? table partitioning? ;) regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings -- Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240 PostgreSQL Replication, Consulting, Custom Programming, 24x7 support Managed Services, Shared and Dedication Hosting Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/ ---(end of broadcast)--- TIP 8: explain analyze is your friend
[HACKERS] Heads up: impending 8.0, 7.4, 7.3 releases
As you probably already read on pgsql-announce, we are looking to release updates in the 7.3 and later branches shortly, due to some recently identified security issues. (BTW, thanks to [EMAIL PROTECTED] for reporting the conversion-function problem.) There's not a definite time set yet, but it'll be in the next couple of days. Anyone have any last-minute fixes they want to get into those releases? regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Feature freeze date for 8.1
> -Original Message- > From: Oliver Jowett [mailto:[EMAIL PROTECTED] > Sent: Monday, May 02, 2005 3:06 PM > To: Chuck McDevitt > Cc: Tom Lane; [EMAIL PROTECTED]; pgsql-hackers@postgresql.org > Subject: Re: [HACKERS] Feature freeze date for 8.1 > > Chuck McDevitt wrote: > > > Why not just use SO_KEEPALIVE on the TCP socket? > > We already do, but the default keepalive interval makes it next to useless. > > -O So, change the default. On Linux it's in /proc/sys/net/ipv4/tcp_keepalive_time Admittedly, this isn't a great solution, but it had the advantage of being simple. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Feature freeze date for 8.1
Chuck McDevitt wrote: > Why not just use SO_KEEPALIVE on the TCP socket? We already do, but the default keepalive interval makes it next to useless. -O ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Feature freeze date for 8.1
On Mon, 2 May 2005, Jim C. Nasby wrote: > FWIW, I've found myself wishing I could set statement_timeout on a per user > or per group basis. Likewise for log_min_duration_statement. > See ALTER USER ... SET Kris Jurka ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] ARCHIVE TABLES (was: possible TODO: read-only tables, select from indexes only.)
On 5/2/05, Jim C. Nasby wrote: > Out of curiosity, what would be required to allow deletes (but not > updates)? The same as updates (because updates are essentially a delete + insert). > My thinking is that you'd want *some* way to be able to prune > data. Since you won't want to store an entire XID/CID for the delete, I > think it would be acceptable to keep a table of XID/CID values for > deletes and just store a pointer to that table in the tuple header. This > means you would be limited (perhaps severely) in the number of deletes > you could issue between vacuums, but for this instance that seems > perfectly reasonable. Since the (pointer to) the visibility information is only stored in the heap, not the index, how are you going to do index-only scans? > Also, how does this allow for index scans without touching the heap? > AFAIK when a tuple is inserted but not committed it is already in the > index. Hannu's design has a table-wide MaxVisibleTID variable. Since the index entry contains the TID it is easy to compare them. I don't think index-only scans are possible with your design. You could use the same hack and add a table-wide MinVisibleTID variable to drop tuples of the other end of the table. I think the advantages of both the ability to append to and delete from an archived table are largely negated with the design for table partitioning as emerging from the work of Simon e.a. on the bizgres list. The advantage of being able to append would be negated by having a partitioned table where you archive certain partitions and all attempts to subsequently append to those partitions are redirected to the catch-all partition. For the delete case that would fit the most common usage pattern of an archive to periodically drop off historic data, is to simply drop an entire partition. Within such a partitioning framework a "CLUSTER partitionname ARCHIVE" operation that truly sets the data in that partition in stone might not be a totally outrageous concept :) Jochem ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Feature freeze date for 8.1
> -Original Message- > From: [EMAIL PROTECTED] [mailto:pgsql-hackers- > [EMAIL PROTECTED] On Behalf Of Tom Lane > Sent: Monday, May 02, 2005 1:17 PM > To: [EMAIL PROTECTED] > Cc: pgsql-hackers@postgresql.org > Subject: Re: [HACKERS] Feature freeze date for 8.1 > > Andrew - Supernews <[EMAIL PROTECTED]> writes: > > Then the client has to guarantee that it can stop whatever it was doing > > (which might have nothing to do with the database) every so often in > > order to send a message; this isn't feasible for most clients. > > It's certainly infeasible for libpq, which has no portable way to force > the calling app to give it control. > > regards, tom lane Why not just use SO_KEEPALIVE on the TCP socket? Then the TCP stack handles sending the keepalive messages, and there is no requirement that the client application give control to anything... It's all handled by the TCP stack. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [pgsql-advocacy] [HACKERS] Decision Process WAS: Increased company involvement
> -Original Message- > From: Tom Lane [mailto:[EMAIL PROTECTED] > Sent: Monday, May 02, 2005 1:50 PM > To: josh@agliodbs.com > Cc: Bruce Momjian; Marc G. Fournier; PostgreSQL advocacy; Dave Held; > PostgreSQL-development > Subject: Re: [pgsql-advocacy] [HACKERS] Decision Process WAS: > Increased > company involvement > > > [...] > Our process is not "democratic" in the sense of any random > subscriber to the mailing lists having the same vote as a > core member --- and I'll bet Boost doesn't run things that > way either. Actually, it does, but it can afford to for very special reasons. Because Boost is not about a single problem domain, there is no real "core" of developers. There are some who have contributed more libraries, or larger libraries; but at the end of the day, each review and submission is judged on its own merits. Often, the person submitting a new library for review is a domain expert for that library; and people reviewing a library are also often domain experts, even if they are a first-time reviewer. So the very nature of Boost allows it to be more democratic. Because Postgres is about a single problem domain, and because each submission must work in concert with an extant whole, it has totally different needs and a totally different type of community. And because a database isn't exactly a modular beast like, say, a web server, that limits the openness of the community further. That is to say, there is a barrier to entry, but it isn't capriciously imposed by the community members. It's just a necessary outcome of the nature of the project. People who want to contribute should understand this barrier and how it works before they start writing code. > What we have is pretty informal but I think it effectively > gives more weight to the opinions of those more involved in > the project; which seems a good way to operate. For Postgres, I agree. > But there isn't anyone here who has an absolute veto, nor > contrarily anyone who can force things in unilaterally over > strong objections. Nor would one expect such a thing in a project that claims to be OSS. But ultimately persuasion is as much a part of consensus as merit, and people should recognize that fact when contributing to the project. __ David B. Held Software Engineer/Array Services Group 200 14th Ave. East, Sartell, MN 56377 320.534.3637 320.253.7800 800.752.8129 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Feature freeze date for 8.1
Tom Lane wrote: > Wouldn't it be reasonable to expect the "cluster liveness machinery" to > notify the database server's kernel that connections to A are now dead? > I find it really unconvincing to suppose that the above problem should > be solved at the database level. Actually, if you were to implement this as you suggest, you either put full-blown group communication in the kernel (ow, no thanks!) or you implement a system where the DB server's kernel has a heartbeat to each peer (e.g. A) and if that heartbeat stops, it kills the corresponding connections. But that functionality already exists: it is SO_KEEPALIVE. (I think we're arguing in circles here..) -O ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Feature freeze date for 8.1
Tom Lane wrote: > Wouldn't it be reasonable to expect the "cluster liveness machinery" to > notify the database server's kernel that connections to A are now dead? No, because it's a node-level liveness test, not a machine-level liveness. It's possible that all that happened is the node's VM crashed. The clustering is all done in userspace. -O ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
On Mon, May 02, 2005 at 01:55:50PM -0400, Bruce Momjian wrote: > Dave Held wrote: > > Of course, it would be quite a bit of work for me to review the > > list and compile instances where I think this has occurred, but > > only because of the tedium involved to make a minor point...not > > because I think I would have difficulty finding evidence. I'm just > > Well, if there was an issue and you had been around for a minimal amount > of time, I would think you could come up with at least one example. I can help with that. Somebody posted a proposal and patch to shrink bloated btree indexes. It's a very interesting feature but nobody replied, so nothing happened. The 2PC patch by Heikki Linnakangas (sp?) is also waiting and so far I haven't seen any indication that it may be merged. This doesn't mean I agree with Dave's argument :-) But there are times when no major contributor has time to "sponsor" a patch or feature, so it goes unnoticed and unmerged. -- Alvaro Herrera (<[EMAIL PROTECTED]>) Voy a acabar con todos los humanos / con los humanos yo acabaré voy a acabar con todos / con todos los humanos acabaré (Bender) ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] pg_locks needs a facelift
On Mon, May 02, 2005 at 04:34:50PM -0400, Merlin Moncure wrote: > Yep. Actually, the biggest part of this was figuring out what to do > about the pg_locks view. Since that's basically decided, all that > remains is to decide what if anything to do about the > max_locks_per_transaction GUC variable. User locks at the very least > are extra-transactional so this could perhaps be renamed. This could > possibly hinge on how Alvaro's 'spill to disk' scenario plays out. Oh, I don't plan to work on locking issues anymore for now. Basically I wanted spill to disk only to serve the tuple locking, but since we solve that in a different way, I pretty much abandoned that idea. -- Alvaro Herrera (<[EMAIL PROTECTED]>) "Por suerte hoy explotó el califont porque si no me habría muerto de aburrido" (Papelucho) ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [pgsql-advocacy] [HACKERS] Decision Process WAS: Increased company involvement
> -Original Message- > From: Bruce Momjian [mailto:[EMAIL PROTECTED] > Sent: Monday, May 02, 2005 3:33 PM > To: Dave Held > Cc: PostgreSQL advocacy; PostgreSQL-development > Subject: Re: [pgsql-advocacy] [HACKERS] Decision Process WAS: > Increased > company involvement > > [...] > Here is a new FAQ entry: > > 1.13) Who controls PostgreSQL? > > If you are looking for a PostgreSQL gatekeeper, > central committee, or controlling company, give up, because > none exists. We do have a core committee and CVS committers, > but these groups are more for administrative purposes then > control. The project is directed by the open community of > developers and users of PostgreSQL. Everyone is welcome to > subscribe and take part in the discussions. (See the > http://www.postgresql.org/docs/faqs.FAQ_DEV.html";> > Developer's FAQ for information on how to get > involved in PostgreSQL development.) > > Adjustments? "...are more for administrative purposes [then->than] control..." Because PostgreSQL is a monolithic product, all of its features must work together in tight harmony. It is in the interests of the PostgreSQL community that new features be integrated in a way that preserves this harmony. Thus, new feature proposals are scrutinized and debated by the community to ensure that changes have sufficient technical merit. Be prepared to defend your proposal, and don't assume that a privately developed contribution will automatically be accepted by the PostgreSQL community. To maximize the chance of success in proposing a change, consider these suggestions: * Propose your change/feature publicly - OSS is about community, and a collection of contributors working independently without communication is not a community; this avoids duplication of effort and promotes collaboration/cooperation among parties that have a common interest * Research your proposal to see if it has already been discussed on the mailing list * Research your proposed solution to make sure it is the best of breed - database technology is a very active subject of academic research, and it is possible, if not likely, that someone has written a paper on the topic * Engage the community by participating in discussions and patch reviews - your credibility as a contributor depends on your willingness to contribute to the community in non-coding ways as well I realize that this runs a bit far afield from the original question of "Who controls PostgreSQL?", but I think it addresses the points that someone who asks this question is likely to want to know. It also tackles the contribution question from a higher level than the dev-faq. Obviously, the bullet points would be formatted as a list or some other appropriate HTML construct. And as a minor point, it would be nice if the website validated to XHTML-strict, although XHTML-transitional would be a good compromise. __ David B. Held Software Engineer/Array Services Group 200 14th Ave. East, Sartell, MN 56377 320.534.3637 320.253.7800 800.752.8129 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] [pgsql-advocacy] Increased company involvement
Jim C. Nasby wrote: On Mon, May 02, 2005 at 04:53:59PM -0400, Andrew Dunstan wrote: See my cross-posting where I specifically state I have no plans for buildfarm to test things outside core. It's doable in principle, but would involve huge amounts of work, for which I at least (as buildfarm's creator/administrator) would not have time in the foreseeable future. Would you be open to someone else adding the capability? And maybe mention that on the buildfarm site? (And before anyone asks, no, this doesn't interest me enough for me to do it :P) Of course. I won't hold my breath waiting, though :-) cheers andrew ---(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] Feature freeze date for 8.1
FWIW, I've found myself wishing I could set statement_timeout on a per user or per group basis. Likewise for log_min_duration_statement. On Mon, May 02, 2005 at 11:38:12PM +0300, [EMAIL PROTECTED] wrote: > On Mon, 02 May 2005 19:53:56 - > Andrew - Supernews <[EMAIL PROTECTED]> wrote: > > >The server-based method is actually no more complex to > >implement on the server end and does not impose any such > restrictions on > >the client (even if the client sets the option and then > ignores the database connection > >for a long time, all that happens is that the TCP window > fills up). > > Yes, any solution on the client side also requires all > client connection interface to be changed..But, at server > side solution only server side would be changed :-) I dont > know it is complex or not. as you know Oracle has a > parameter to implement that solution on the server side. > > Best Regards, > > Adnan DURSUN > ASRIN Bili?im Hiz.Ltd. > > ---(end of broadcast)--- > TIP 9: the planner will ignore your desire to choose an index scan if your > joining column's datatypes do not match > -- Jim C. Nasby, Database Consultant [EMAIL PROTECTED] Give your computer some brain candy! www.distributed.net Team #1828 Windows: "Where do you want to go today?" Linux: "Where do you want to go tomorrow?" FreeBSD: "Are you guys coming, or what?" ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [pgsql-advocacy] [HACKERS] Decision Process WAS: Increased company
while you weren't looking, Bruce Momjian wrote: > Adjustments? A couple slight tweaks and rephrasings: If you're looking for a PostgreSQL gatekeeper, central committe or controlling company, give up; there isn't one. We do have a core committe and don't hand out CVS commit privileges like candy, but this is more for ease of administration than control. The project is driven by the needs of the community of developers and users, which anyone can join. All you need to do is subscribe to the mailing list(s) and participate in the discussions. (See the http://www.postgresql.org/faqs.FAQ_DEV.html";>Developer's FAQ for more information on how to get involved in PostgreSQL development.) /rls -- :wq ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [pgsql-advocacy] [HACKERS] Decision Process WAS: Increased company
while you weren't looking, I wrote: [...] Gah. s/committe/committee/ /rls -- :wq ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] ARCHIVE TABLES (was: possible TODO: read-only tables, select from indexes only.)
Out of curiosity, what would be required to allow deletes (but not updates)? My thinking is that you'd want *some* way to be able to prune data. Since you won't want to store an entire XID/CID for the delete, I think it would be acceptable to keep a table of XID/CID values for deletes and just store a pointer to that table in the tuple header. This means you would be limited (perhaps severely) in the number of deletes you could issue between vacuums, but for this instance that seems perfectly reasonable. It might be worth using this same technique for inserts as well. If the only inserting into the table is from some nightly bulk process, you certainly don't need to store 4 (or is it 8) bytes of inserting transaction data with each tuple. Also, how does this allow for index scans without touching the heap? AFAIK when a tuple is inserted but not committed it is already in the index. -- Jim C. Nasby, Database Consultant [EMAIL PROTECTED] Give your computer some brain candy! www.distributed.net Team #1828 Windows: "Where do you want to go today?" Linux: "Where do you want to go tomorrow?" FreeBSD: "Are you guys coming, or what?" ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] [pgsql-advocacy] Increased company involvement
On Mon, May 02, 2005 at 04:53:59PM -0400, Andrew Dunstan wrote: > See my cross-posting where I specifically state I have no plans for > buildfarm to test things outside core. It's doable in principle, but > would involve huge amounts of work, for which I at least (as buildfarm's > creator/administrator) would not have time in the foreseeable future. Would you be open to someone else adding the capability? And maybe mention that on the buildfarm site? (And before anyone asks, no, this doesn't interest me enough for me to do it :P) -- Jim C. Nasby, Database Consultant [EMAIL PROTECTED] Give your computer some brain candy! www.distributed.net Team #1828 Windows: "Where do you want to go today?" Linux: "Where do you want to go tomorrow?" FreeBSD: "Are you guys coming, or what?" ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Feature freeze date for 8.1
Hi,
-- [EMAIL PROTECTED] wrote:
> So this means, If client does never try to send data the
> resources would be going to be held.
> I think it is not a good solution to find zombie / dead
> connection and clear them..
With TCP/IP you DON'T have any other options then waiting for a timeout. In
one or another way. This is a feature of TCP connections.
But when happens this?
A) when you unplug the client or server from the net without shutdown
B) when you firewall the client or server ("deny all from any to any")
When one of this happens, there is another serious problem. First you should
handle this.
AFAIK is A) managable by switches our routers.
With SO_KEEPALIVE there is a chance to detect dead connections earlyer: when
sending or receiving data. Perhaps it is possible to write a daemon, which
surveys all open sockets of a machine and kills the owner of any dead socket.
But this something for the OS, not for PostgreSQL.
Another option is to check periodical with select (2) the connections
(instead of sending/receiving something); I'm not a TCP/IP specialist, but
perhaps this helps in these rare situations, when the user knows that the
connections between server and client break often. This needs a lot of
changes in the PG backend, I guess. And it may cost performance, so please
only as compile time switch.
Because someone mentioned MySQL as positive example: that's wrong. MySQL *can
not* handle broken/cloded connections, when the remote machine is gone (e.g.
firewalled or unplugged). I had this scenario some weeks ago: the client was
sending queries to the server, and the firewall blocked them (because before
this query the socket was about 5 minutes idle); the whole application was
blocked.
Ciao
Alvar
Alvar C.H. Freude -- http://alvar.a-blast.org/
http://odem.org/
http://www.assoziations-blaster.de/info/Hommingberger-Gepardenforelle.html
http://www.assoziations-blaster.de/
---(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] [pgsql-advocacy] Increased company involvement
Ron Mayer wrote: * I'd like to see the status of pgFoundry projects on http://www.pgbuildfarm.org/cgi-bin/show_status.pl Right now I have confidence in most of the contrib modules largely because I can quickly see if they succeed or fail. I'd like any pgFoundry project that is released into the table described above to also have regression tests that must pass before they're included in that table. Ideally, I'd like to be able to see those results for any released PGFoundry projects run on pgbuildfarm as well so the status is easily visible. See my cross-posting where I specifically state I have no plans for buildfarm to test things outside core. It's doable in principle, but would involve huge amounts of work, for which I at least (as buildfarm's creator/administrator) would not have time in the foreseeable future. cheers andrew ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] pg_locks needs a facelift
On Mon, May 02, 2005 at 02:12:33PM -0400, Merlin Moncure wrote: > > "Merlin Moncure" <[EMAIL PROTECTED]> writes: > > Fair enough, although I think that at least one major application of > > user locks would be equivalent to tuple locks. Somebody was asking > > for named user locks in the previous thread, and the easiest way to > > get that is to make a table containing just lock names, and then lock > > on the CTIDs of that table. Since there would be no reason to allow > > UPDATE or DELETE in such a table, the putative instability of CTID > > doesn't really matter. > > This is fine, but relying on structures outside of shared memory is a > fairly hefty price. User locks are very fast and tight and incur zero > maintenance overhead...with a table you have to consider vacuuming > strategies + possible reindex for the unique constraint...bleh. If the > lock table was not synced and auto-vacuumed, then maybe it could work. > I also wonder if there would be a race condition if someone tried to > acquire ctid based named lock at the same time a user lock with the same > value, unless ctid locks were maintained in a separate hash table. Well, there's nothing that says you have to actually refer to locks by name. When I proposed this what I proposed is that the userlock module provide a dedicated means to map a lock name to a lock number, and reserve one of the 'lock spaces' (the 16 bit number) for this use, just as one of them is currently reserved for locks based on OID. But I also can't think of any reason why lock names need to be persistent, so I imagine you could store a list of lock names in shared memory with no backing storage. -- Jim C. Nasby, Database Consultant [EMAIL PROTECTED] Give your computer some brain candy! www.distributed.net Team #1828 Windows: "Where do you want to go today?" Linux: "Where do you want to go tomorrow?" FreeBSD: "Are you guys coming, or what?" ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Feature freeze date for 8.1
On Mon, 02 May 2005 19:53:56 - Andrew - Supernews <[EMAIL PROTECTED]> wrote: >The server-based method is actually no more complex to >implement on the server end and does not impose any such restrictions on >the client (even if the client sets the option and then ignores the database connection >for a long time, all that happens is that the TCP window fills up). Yes, any solution on the client side also requires all client connection interface to be changed..But, at server side solution only server side would be changed :-) I dont know it is complex or not. as you know Oracle has a parameter to implement that solution on the server side. Best Regards, Adnan DURSUN ASRIN Bilişim Hiz.Ltd. ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
I thought it was still maintained? Right, but it should be moved out of our CVS, I think. Agreed ... if someone can make the project, I can move the CVS files over ... does anyone know who is currently maintaining it though? I can make the project but I obviously have no desire to maintain it. Sincerely, Joshua D. Drake -- Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240 PostgreSQL Replication, Consulting, Custom Programming, 24x7 support Managed Services, Shared and Dedication Hosting Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/ ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] pg_locks needs a facelift
FWIW, I've asked previously for a means to name userlocks. The reason for this is that if you're not locking on some kind of object with an OID then you're stuck picking some random value and hoping that no one else using userlock ever picks the same value. If instead there was a means to name userlocks, it's easy to use a name like "My application: some thing I want to block on". Putting the 'My application:' in there pretty much ensures that you won't conflict with anything else, and the randomness of whatever you call what you're locking on should be plenty to handle the rest. On Mon, May 02, 2005 at 01:30:49PM -0400, Tom Lane wrote: > "Merlin Moncure" <[EMAIL PROTECTED]> writes: > > I don't like the idea of listing user locks with 'tuple' locks for no > > other reason than this might confuse what user locks are. > > Fair enough, although I think that at least one major application of > user locks would be equivalent to tuple locks. Somebody was asking > for named user locks in the previous thread, and the easiest way to > get that is to make a table containing just lock names, and then lock > on the CTIDs of that table. Since there would be no reason to allow > UPDATE or DELETE in such a table, the putative instability of CTID > doesn't really matter. > > However, displaying them as object locks certainly works, and you'd have > to put some intelligence in front of the view anyway about what meaning > you were assigning to user locks in your installation. So you can > always cast to whatever you need. > > > IMO, this is a problem with the current user lock module...it > > encourages locking over oid which is a bad practice. A properly > > implemented user lock system would likely maintain a global sequence > > shared by all lockable objects, tuple or otherwise. > > Certainly the current contrib/userlock code could stand a rewrite. > Or more likely, addition of new functions --- we should deprecate > the old ones, but I see no need to remove 'em right away. > > regards, tom lane > > ---(end of broadcast)--- > TIP 4: Don't 'kill -9' the postmaster > -- Jim C. Nasby, Database Consultant [EMAIL PROTECTED] Give your computer some brain candy! www.distributed.net Team #1828 Windows: "Where do you want to go today?" Linux: "Where do you want to go tomorrow?" FreeBSD: "Are you guys coming, or what?" ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] [pgsql-advocacy] Increased company involvement
Marc G. Fournier wrote: That is what pgFoundry was setup for ... to give projects the visibiilty they would get through the core distribution by making sure they are referenced in a central place, but providing the maintainers with direct CVS access to make changes to their code in a timely manner .. *shrug* As a user, I think it's not that PGFoundry projects are second-class projects because of where they live. I think they're second-class projects because there is less visibility into the version computability of those projects with postgresql compared to those in contrib. Note that this has nothing to do with a project being "part of core" - it's largely an documentation/organization issue of pgFoundry itself. I think a few changes to pgFoundry would make packages that live there much more viable. * I'd like to be able to clearly see what version of a given pgFoundry project works with which PostgreSQL major release. I'd like this to be consistent among all pgFoundry versions so I can very quickly and easily find the package I need. 7.3.X7.4.X 8.0.X nightly_cvs pgpool: plhaskel: [...] and within that table, I'd want links to source tarballs, and possibly whatever RPMs, WindowsInstallers, etc work and have been tested with the given postgresql release. It's OK for that table to be mostly empty for projects that have not been tested with many versions, but if a link is in there there, it'd be a nice way of knowing if, for example, plFortran works with old versions (7.3.X) or if it's been ported to the latest version. * I'd like to see the status of pgFoundry projects on http://www.pgbuildfarm.org/cgi-bin/show_status.pl Right now I have confidence in most of the contrib modules largely because I can quickly see if they succeed or fail. I'd like any pgFoundry project that is released into the table described above to also have regression tests that must pass before they're included in that table. Ideally, I'd like to be able to see those results for any released PGFoundry projects run on pgbuildfarm as well so the status is easily visible. Even if there's no automated testing involved, I think it'd be nice if that first table existed; and we could just trust the developers of each project to put the right tarballs in the right spots in the table. I'm wildly guessing that this more limited scope should be a relatively easy first-step in this direction? ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] PostgreSQL Guru needed: $70K - $80K year!!
PLEASE RESPOND WITH A (.DOC) COPY OF YOUR RESUME Position Summary: Our client is looking for a singular candidate to drive the overall database strategy for their fast-growing office in Skokie, IL. Our client has over 300 PostgreSQL databases, which roll up nightly into Oracle Warehouses. This is a full time position. The ideal candidate would not only be able to see growing trends and practices in Data Warehousing and help drive vision three to five years ahead, but also enjoys getting hands-on and rebuilding indexes on a local level when production machines need tending. Special Skills/Experience Required: Under supervision of the Chief Engineer, install, configure, maintain, troubleshoot and tune multiple Data Warehousing databases running on RedHat Enterprise Linux. Administer databases through full application life cycle: development, testing, and production. Provide guidance and mentoring to a Junior DBA and set tone for the team. Monitor ongoing data trends in their fleet of 300 PostgreSQL servers. Perform database logical and physical design. Provide requirements definitions for backup/recovery procedures. Qualifications: Strong analytical and problem solving skills. Must be self-motivated and be able to grasp functional concepts quickly. Excellent verbal and writing skills required. Must be able to work independently and participate as a member of a cross-functional team. B.S. in Computer Science or other technical degree or equivalent work experience required. 5-7 years of post-graduate experience in IT, 3+ years as an Oracle DBA. Data architecture, systems integration, database design, application SQL and database tuning, space management, database monitoring, and RMAN backup/recovery experience required. Experience with UNIX systems necessary, Red Hat Linux a plus. Experience with PostgreSQL not necessary, but a plus. ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] pg_locks needs a facelift
> > well, the old ones are GPL. I've made a few attempts to contact the > > original author...he's MIA. Since 95% of the implementation is in the > > backend, it seems odd to have a GPL interface. > > I agree. Wasn't it you that was proposing to rewrite the module from > scratch to eliminate the GPL restriction? > > regards, tom lane Yep. Actually, the biggest part of this was figuring out what to do about the pg_locks view. Since that's basically decided, all that remains is to decide what if anything to do about the max_locks_per_transaction GUC variable. User locks at the very least are extra-transactional so this could perhaps be renamed. This could possibly hinge on how Alvaro's 'spill to disk' scenario plays out. FWIW, I'm a huge fan of the current behavior which is to drop transactions when running out of lock-space. In any event, I'll rewrite the interface and the documentation for user-locking with minimal changes except to expose more of the locktag structure and remove references to the deprecated and conceptually confusing oid. Merlin ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [pgsql-advocacy] [HACKERS] Decision Process WAS: Increased company
Dave Held wrote: > > -Original Message- > > From: Josh Berkus [mailto:[EMAIL PROTECTED] > > Sent: Monday, May 02, 2005 1:21 PM > > To: Bruce Momjian > > Cc: Marc G. Fournier; PostgreSQL advocacy; Dave Held; > > PostgreSQL-development > > Subject: Re: [pgsql-advocacy] [HACKERS] Decision Process WAS: > > Increased > > company involvement > > > > [...] > > Hmmm ... why does everyone assume that Core does more than > > what we do? I think that most people would be surprised by > > how *little* traffic there is on the pgsql-core mailing list. > > Well, I never said that core runs around saving the world. I > mostly made the point that core developers have special > influence, and that should be considered when contributing to > Postgres, which is directly relevant to the point of the > thread, which was originally called "Increased company > involvement." Here is a new FAQ entry: 1.13) Who controls PostgreSQL? If you are looking for a PostgreSQL gatekeeper, central committee, or controlling company, give up, because none exists. We do have a core committee and CVS committers, but these groups are more for administrative purposes then control. The project is directed by the open community of developers and users of PostgreSQL. Everyone is welcome to subscribe and take part in the discussions. (See the http://www.postgresql.org/docs/faqs.FAQ_DEV.html";> Developer's FAQ for information on how to get involved in PostgreSQL development.) Adjustments? -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
Marc G. Fournier wrote: The issue is that we have had to wack around the existing PL languages for almost every release to make them work with server changes, and being outside our CVS, plPHP isn't getting that whacking. And the point is, as Tom has pointed out with tsearch2, that even *in* CVS, it is a fair amount of work to 'whack' other ppls code ... it shouldn't be Tom's responsibility (which is generally what it comes down to) to keep someone else's code up to speed with changes in the server ... Just to reiterate a previous point I have made: buildfarm does build (and mostly test) things in the core. I have *no* plans at all to make it test things not in core - currently we get code from one source and it would be a huge effort to change that. I *do* have plans to make it run the tests for each PL in core, if they are configured in the build. So be careful about pushing or keeping out of core things that are now or will soon get buildfarm testing. The argument about tarball size I can't take seriously - the plperl directory for example takes 148k uncompressed in a distribution of 72 Mb. I agree that contrib needs some considerable cleanup. For example, is there any good reason not to fold in the crypto stuff? cheers andrew ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
On Mon, May 02, 2005 at 12:39:27PM -0500, Dave Held wrote: > > -Original Message- > > From: Bruce Momjian [mailto:[EMAIL PROTECTED] > > Sent: Monday, May 02, 2005 12:17 PM > > To: PostgreSQL advocacy > > Cc: Dave Held; PostgreSQL-development > > Subject: Re: [pgsql-advocacy] [HACKERS] Increased company involvement > > > > > [...] > > > Really? You have a different perspective than I see. I have > > > seen patches be accepted that had no core buy-in. We accept > > > patches based on group feedback, not some closed approval > > > process. > > > > Let me also ask for you to provide an example of the behavior you > > describe. > > Well, I think there's numerous examples where someone suggests some > feature or idea, and Tom or one or two other core developers will > say: "I don't like that idea", and then the proposer will more or > less give up on it because it is clear that it won't go anywhere. > So whether the process gets stopped at the patch submission level > or the feature proposal level isn't really relevant. It seems pretty > clear that a handful of people decide the direction of Postgres, > and everyone else can either contribute to the features that have > been agreed to be acceptable and relevant, or they can fork their > own version. I don't think it's valid to attribute this to the core team at all, but I do understand what you're saying. Part of this is that many people like to see data to back up a claim before adding complexity to the database. The current read-only table discussion is a good example. How much will it actually help to have a means to reduce the size of HeapHeaderData? The problem is many times it's very hard to come up with this data without actually coding something up and trying it. As Josh B. pointed out in another post, sometimes people will suggest something on -hackers and it just dies on the vine. This doesn't mean it wouldn't be useful, it means no one on hackers was interested. But for every user who's on hackers there's probably 10 than aren't and who knows how many who might become users if some feature was added. Personally, I think that the current process could do a better job of gauging how much user interest there is in changes that are in the gray area between 'wow, that's a great idea!' and 'wow, that's a horrid idea!'. There's also the issue of people making suggestions to try and address a larger problem. I think read-only tables is a good example; the real issue is that in many data-mining applications the 30 byte overhead on tuples is huge, and puts postgresql at a big disadvantage. Read-only tables would definately be difficult to implement, but they *could* provide a tremendous benefit to PostgreSQL performance in certain applications. Of course, there's other changes that could also provide benefits, such as a means to keep a table clustered (or nearly clustered). But these things have generally been shot-down in the past, and the data warehousing disadvantage continues. Now I'm not suggesting that the process is seriously broken, but I do think that the interests and experiences of the most active developers tend to keep us away from changes that would only help a subset of users (or potential users). I also think it would be better if that subset was heard better. Data warehousing is the current example that comes to mind, but I'm certain there are others. -- Jim C. Nasby, Database Consultant [EMAIL PROTECTED] Give your computer some brain candy! www.distributed.net Team #1828 Windows: "Where do you want to go today?" Linux: "Where do you want to go tomorrow?" FreeBSD: "Are you guys coming, or what?" ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
On Mon, 2 May 2005, Bruce Momjian wrote: Joshua D. Drake wrote: Marc G. Fournier wrote: On Mon, 2 May 2005, Bruce Momjian wrote: Why is dbmirror still there? Can't it be moved to pgfoundry? Anyone willing to take ownership of it to setup the project itself on pgfoundry? I thought it was still maintained? Right, but it should be moved out of our CVS, I think. Agreed ... if someone can make the project, I can move the CVS files over ... does anyone know who is currently maintaining it though? Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Feature freeze date for 8.1
Andrew - Supernews <[EMAIL PROTECTED]> writes: > Then the client has to guarantee that it can stop whatever it was doing > (which might have nothing to do with the database) every so often in > order to send a message; this isn't feasible for most clients. It's certainly infeasible for libpq, which has no portable way to force the calling app to give it control. 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: [pgsql-advocacy] [HACKERS] Increased company involvement
Bruce Momjian writes: > Joshua D. Drake wrote: >> Marc G. Fournier wrote: >>> Anyone willing to take ownership of it to setup the project itself on >>> pgfoundry? >> >> I thought it was still maintained? > Right, but it should be moved out of our CVS, I think. Didn't someone offer a rewritten version of dbmirror just this morning? Maybe that person could be persuaded to run a pgfoundry project. dbmirror is certainly a fine example of something that doesn't need to be in the core distro as far as maintenance is concerned. Of course, it's also not large enough to make much of a difference in tarball size. 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: [pgsql-advocacy] [HACKERS] Increased company involvement
Joshua D. Drake wrote: > Marc G. Fournier wrote: > > On Mon, 2 May 2005, Bruce Momjian wrote: > > > >> Why is dbmirror still there? Can't it be moved to pgfoundry? > > > > > > Anyone willing to take ownership of it to setup the project itself on > > pgfoundry? > > I thought it was still maintained? Right, but it should be moved out of our CVS, I think. -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
Bruce Momjian wrote: Joshua D. Drake wrote: Marc G. Fournier wrote: On Mon, 2 May 2005, Bruce Momjian wrote: Why is dbmirror still there? Can't it be moved to pgfoundry? Anyone willing to take ownership of it to setup the project itself on pgfoundry? I thought it was still maintained? Right, but it should be moved out of our CVS, I think. We may as well include the mSQL-interface ;) in the removal process. Sincerely, Joshua D. Drake -- Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240 PostgreSQL Replication, Consulting, Custom Programming, 24x7 support Managed Services, Shared and Dedication Hosting Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/ ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
Marc G. Fournier wrote: On Mon, 2 May 2005, Bruce Momjian wrote: Why is dbmirror still there? Can't it be moved to pgfoundry? Anyone willing to take ownership of it to setup the project itself on pgfoundry? I thought it was still maintained? Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 8: explain analyze is your friend -- Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240 PostgreSQL Replication, Consulting, Custom Programming, 24x7 support Managed Services, Shared and Dedication Hosting Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/ ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
On Mon, 2 May 2005, Bruce Momjian wrote: Why is dbmirror still there? Can't it be moved to pgfoundry? Anyone willing to take ownership of it to setup the project itself on pgfoundry? Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [pgsql-advocacy] [HACKERS] Decision Process WAS: Increased company
Tom Lane wrote: > Josh Berkus writes: > > As you've already observed, if Tom doesn't like something it's very > > unlikely > > to get through. > > I lose my share of arguments --- in fact, in the twenty minutes since > your posting I already notice Bruce committing a patch I had objected to > ;-). I replied to your concerns on Saturday night, and when I saw no community response by noon today, I assume everyone as OK and applied it. I suppose this is as good an illustration of the process as we are going to get. -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(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] Feature freeze date for 8.1
On 2005-05-02, Rob Butler <[EMAIL PROTECTED]> wrote: > Another option is to have the client driver send some > ignorable message instead of the server. If the > server doesn't get a message every timeout > minutes/seconds + slop factor, then it drops the > connection. So libpq, JDBC, .net etc would all have > to have this implemented, but the changes to the > server would probably be simpler this way, wouldn't they? Then the client has to guarantee that it can stop whatever it was doing (which might have nothing to do with the database) every so often in order to send a message; this isn't feasible for most clients. The server-based method is actually no more complex to implement on the server end and does not impose any such restrictions on the client (even if the client sets the option and then ignores the database connection for a long time, all that happens is that the TCP window fills up). -- Andrew, Supernews http://www.supernews.com - individual and corporate NNTP services ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
Marc G. Fournier wrote: > On Mon, 2 May 2005, Joshua D. Drake wrote: > > >> > >> I'm not pointing fingers at you either :) But, you are one of how many > >> that try and get 'added to core'? How many things do we have in contrib > >> that the only person that does any 'whacking' is Tom? A couple I've seen > >> patches go around for, but for a good portion of them, I imagine that they > >> are 'dead except that Tom keeps fixing them' ... > > > > In contrib I would bet a lot. I have argued for the removal of TSearch (not > > TSearch2) for example. Also RServ could probably stand to be removed. > > rserv was removed long ago ... not sure why tsearch is in there stil > though ... Why is dbmirror still there? Can't it be moved to pgfoundry? -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(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] Feature freeze date for 8.1
On Mon, May 02, 2005 at 12:29:33 -0700, Rob Butler <[EMAIL PROTECTED]> wrote: > > > One way to handle this is to have an option, set by > > the client, that > > causes the server to send some ignorable message > > after a given period > > of time idle while waiting for the client. If the > > idleness was due to > > network partitioning or similar failure, then this > > ensures that the > > connection breaks within a known time. This is safer > > than simply having > > the backend abort after a given idle period. > > Another option is to have the client driver send some > ignorable message instead of the server. If the > server doesn't get a message every timeout > minutes/seconds + slop factor, then it drops the > connection. So libpq, JDBC, .net etc would all have > to have this implemented, but the changes to the > server would probably be simpler this way, wouldn't they? Except it won't work, because the server is who needs to know about the problem. If the network is down, you can't send a TCP RST packet to close the connection on the server side. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
On Mon, 2 May 2005, Joshua D. Drake wrote: I'm not pointing fingers at you either :) But, you are one of how many that try and get 'added to core'? How many things do we have in contrib that the only person that does any 'whacking' is Tom? A couple I've seen patches go around for, but for a good portion of them, I imagine that they are 'dead except that Tom keeps fixing them' ... In contrib I would bet a lot. I have argued for the removal of TSearch (not TSearch2) for example. Also RServ could probably stand to be removed. rserv was removed long ago ... not sure why tsearch is in there stil though ... If it isn't in core, it is a second class project. Regardless of how we all "want" to feel about it. As you've seen in the note that I sent to you ... my biggest 'beef' against continually adding things is the download size just keeps growing, and when someone already has the core installed, having to redownload it because they've decided to add something like pl/PHP when pl/PHP doesn't need anything but the headers/libraries that are already installed seems idiotic at best ... if some method of extending 'make dist' for the release cycle can be devised so that pl/PHP (and the other pl/'s would be nice eventually) tar *with* the core .tar.gz *and* a seperate plphp-.tar.gz file that can be downloaded seperately, my arguments against will have been negated ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(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] Feature freeze date for 8.1
> One way to handle this is to have an option, set by > the client, that > causes the server to send some ignorable message > after a given period > of time idle while waiting for the client. If the > idleness was due to > network partitioning or similar failure, then this > ensures that the > connection breaks within a known time. This is safer > than simply having > the backend abort after a given idle period. Another option is to have the client driver send some ignorable message instead of the server. If the server doesn't get a message every timeout minutes/seconds + slop factor, then it drops the connection. So libpq, JDBC, .net etc would all have to have this implemented, but the changes to the server would probably be simpler this way, wouldn't they? __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.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: [pgsql-advocacy] [HACKERS] Increased company involvement
As someone who has made a few minor contributions and plenty of suggestions, but who is not on the core team, I would like to offer my observations. Every suggestion I have ever made that had any merit at all has eventually worked its way into PostgreSQL (most -- perhaps all -- were already under consideration). The dumb ideas I coughed up were neatly shot down in flames as they should have been. The PostgreSQL project is very well run, in fact amazingly well considering the loose structure of an open source project. There are a few things that might be accomplished a bit differently, but I do not know how it would be possible to architect it (for instance, I would completely divorce the testing team from the development team since that is how it is usually done with commercial systems). IMO-YMMV. > -Original Message- > From: [EMAIL PROTECTED] [mailto:pgsql-hackers- > [EMAIL PROTECTED] On Behalf Of Bruce Momjian > Sent: Monday, May 02, 2005 10:56 AM > To: Dave Held > Cc: PostgreSQL-development; PostgreSQL advocacy > Subject: Re: [pgsql-advocacy] [HACKERS] Increased company involvement > > Dave Held wrote: > > Just watching the hackers list suggests to me that this is the norm, > > rather than the exception. I guess I'm interested to see which > > patches have been accepted that the core developers opposed. Now > > don't get me wrong. Sometimes there are good technical reasons why > > feature A or B can't or shouldn't be added or even developed. And > > I don't suggest that patches lacking technical merit should not be > > rejected. But sometimes it seems that ideas with undetermined > > merit get passed over because of a quick judgement based on > > intuition, and only if the proposer actively fights for it for a > > while does it get reconsidered. > > > > Of course, it would be quite a bit of work for me to review the > > list and compile instances where I think this has occurred, but > > only because of the tedium involved to make a minor point...not > > because I think I would have difficulty finding evidence. I'm just > > Well, if there was an issue and you had been around for a minimal amount > of time, I would think you could come up with at least one example. > > > saying that as an outsider, if I had a lot of resources to devote > > to contributing to Postgres, I would only consider working on > > approved TODO items or making sure I more or less had core buy-in > > before writing any code. I don't think it would be worth my > > time to work on something that non-core users/developers might > > like but core hackers don't. > > Well, our developer's FAQ clearly states you should communicate your > ideas to the hackers list before starting work to be sure you have > _community_ buy-in, rather than core buy-in. > > And the TODO list is not a core list, it is accumulated from community > suggestions and discussion. > > > Like I said, that's not necessarily a bad thing. Postgres is a > > piece of software with many interacting components, and there > > needs to be some coordination to make sure it evolves in a > > sensible way. But I think that implies that there must be and > > is some de facto centralization of control, whether that is the > > published ideology or not. > > I will give you the example of adding a read-only table as an example. I > am betting the idea will not be accepted because the costs outweight the > gain, but I will post my opinions on the list and others will as well > and we will come to some concensus. If X members feel something is bad, > and 5X members think something is good, it almost always gets in --- it > doesn't matter if all the core people are in X or not. > > Another example is the recent patch to check if there are orphaned file > system files. That was submitted, Tom had questions, I posted why I > thought it was valid, and the patch is going in today. Anyone has the > ability to argue their point and try to sway the community, and any > member has the right to request a vote on a specific issue. > > Perhaps we are more a replublic because we do defer our judgement to > others who have looked into the area more thoroughly. > > -- > Bruce Momjian| http://candle.pha.pa.us > pgman@candle.pha.pa.us | (610) 359-1001 > + If your life is a hard drive, | 13 Roberts Road > + Christ can be your backup.| Newtown Square, Pennsylvania > 19073 > > ---(end of broadcast)--- > TIP 9: the planner will ignore your desire to choose an index scan if your > joining column's datatypes do not match ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [pgsql-advocacy] [HACKERS] Decision Process WAS: Increased company involvement
On Monday 02 May 2005 14:49, Josh Berkus wrote:
> Bruce,
>
> > > (P.S. on a complete tangent, "call a spade a spade" is actually a
> > > racist expression originating in the reconstruction-era South.
> > > "spade" does
> >
> > You must be from California. :-)
>
> Well, yes. Actually, from San Francisco, which is even worse.And I
> just spent the weekend in Orange County which really gotten my PC dander
> up. Sorry, Dave!
And this is why I hate the PC movement... The phrase calling a spade a spade
pre-dates the U.S. as whole, much less the reconstruction-era South. It is
believed to have been introduced into the english language via John Knox in
the 1500's who wrote "I have learned to call wickedness by its own terms: A
fig, a fig, and a spade a spade", borrowing from an earlier latin text, which
is believed to be based on an even earlier Greek writer.
--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
Marc G. Fournier wrote: > On Mon, 2 May 2005, Joshua D. Drake wrote: > > >>> > >>> The issue is that we have had to wack around the existing PL languages > >>> for almost every release to make them work with server changes, and > >>> being outside our CVS, plPHP isn't getting that whacking. > >> > >> > >> And the point is, as Tom has pointed out with tsearch2, that even *in* > >> CVS, > >> it is a fair amount of work to 'whack' other ppls code ... it shouldn't be > >> Tom's responsibility (which is generally what it comes down to) to keep > >> someone else's code up to speed with changes in the server ... > > > > Well we try to keep up :) > > I'm not pointing fingers at you either :) But, you are one of how many > that try and get 'added to core'? How many things do we have in contrib > that the only person that does any 'whacking' is Tom? A couple I've seen > patches go around for, but for a good portion of them, I imagine that they > are 'dead except that Tom keeps fixing them' ... > > Tom's focus shouldn't be making sure that everyone's third party add on > "still works" during a release cycle, that should be the responsibility of > the maintainers of those projects, to follow changes and make sure they > are implemented ... > > That is what pgFoundry was setup for ... to give projects the visibiilty > they would get through the core distribution by making sure they are > referenced in a central place, but providing the maintainers with direct > CVS access to make changes to their code in a timely manner .. *shrug* > The bottom line is that it is more efficient for one person to adjust all the PL's at once rather than each PL learning about the changes and making them. -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
Andrew Dunstan wrote: I've deliberately let the dust settle slightly on this. One thing that might help is a more open sponsorship "clearing house". Example (not meant as a bid, but just to illustrate): the JDBC driver needs a scanner overhaul - it breaks on dollar quoting and a bunch of other stuff. I could do that work (as could others, of course) but I don't have time, unless someone buys some of my professional time. Someone might want to do just that, but how would they find me? Regarding the secret code stuff - I predict that it will quickly bite whoever does it, unless they are extremely lucky. I like this idea. There is another issue too. In general, there is a feeling like one needs to produce something that works and not wait for the slower movement of the community's approval. I don't think several open source forks for the project necessarily produce problems if most of these are used as experimental projects. The example which comes to mind is Samba-TNG. So some of this concern may be overblown. This is also the way things work with the SQL Standard: The various vendors (PostgreSQL included) go out and start with the base, extend that feature set, and eventually come back together to try to build the next standard based on everyone's experience. This embrace and extend process is indeed critical for the further development of the standard. At the same time, I agree with Bruce's main point-- that the lack of communication is a threat to this progress. So at least some note of "Best practices" regarding these extensions or contributions would be a help. Adding a clearing house to this would also add a critical tool and would also have the side effect of increasing the pace of development. Maybe have it divided into two sections: Bids and Bounties. Best Wishes, Chris Travers Metatron Technology Consulting ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
Marc G. Fournier wrote: > On Mon, 2 May 2005, Bruce Momjian wrote: > > > Marc G. Fournier wrote: > >> On Mon, 2 May 2005, Bruce Momjian wrote: > >> > >>> Marc G. Fournier wrote: > On Mon, 2 May 2005, Bruce Momjian wrote: > > > I posted this compromise and no one replied so I thought everyone was OK > > with it. It gets it into CVS, but has a separate compile stage to deal > > with the recursive dependency problem. > > Then what is the point of having it in CVS? Other then to make are tar > ball bigger? > >>> > >>> So it can be maintained with other PL languages as the internal API > >>> changes. This is the same reason ecpg is in our CVS because it is tied > >>> to the grammar. > >> > >> Since when? I thought you didn't need the PostgreSQL sources in order to > >> compile pl/PHP, only the installed headers/libraries ... Joshua, has > >> something changed, or did I mis-understand that requirement? > > > > The issue is that we have had to wack around the existing PL languages > > for almost every release to make them work with server changes, and > > being outside our CVS, plPHP isn't getting that whacking. > > And the point is, as Tom has pointed out with tsearch2, that even *in* > CVS, it is a fair amount of work to 'whack' other ppls code ... it > shouldn't be Tom's responsibility (which is generally what it comes down > to) to keep someone else's code up to speed with changes in the server ... When a PL languages is so tied to the changing API that it will only work for a single major release of PostgreSQL, like ecpg, it is usually kept in our CVS. This isn't true of odbc, jdbc, or other stuff, and not even Slony. -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
I'm not pointing fingers at you either :) But, you are one of how many that try and get 'added to core'? How many things do we have in contrib that the only person that does any 'whacking' is Tom? A couple I've seen patches go around for, but for a good portion of them, I imagine that they are 'dead except that Tom keeps fixing them' ... In contrib I would bet a lot. I have argued for the removal of TSearch (not TSearch2) for example. Also RServ could probably stand to be removed. However we are not talking about contrib (or at least I am not). We were talking about PLs which are a little bit of a different beast. Tom's focus shouldn't be making sure that everyone's third party add on "still works" during a release cycle, that should be the responsibility of the maintainers of those projects, to follow changes and make sure they are implemented ... I would agree, I suggested test cases for contrib once. I think that would be very good. If the contrib fails the test case for itself say after (this could go for pls to) Beta2 then it gets yanked. That is what pgFoundry was setup for ... to give projects the visibiilty they would get through the core distribution by making sure they are referenced in a central place, but providing the maintainers with direct CVS access to make changes to their code in a timely manner .. *shrug* It was what pgFoundry was setup for but as I have said elsewhere perception is everything. If it isn't in core, it is a second class project. Regardless of how we all "want" to feel about it. Sincerely, Joshua D. Drake Command Prompt, Inc. -- Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240 PostgreSQL Replication, Consulting, Custom Programming, 24x7 support Managed Services, Shared and Dedication Hosting Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/ ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [pgsql-advocacy] [HACKERS] Decision Process WAS: Increased company
Josh Berkus wrote: > Dave, > > > Well, I never said that core runs around saving the world. I > > mostly made the point that core developers have special > > influence, > > Yep. Absolutely. I wanted to point out to you that core isn't the only > group within PostgreSQL that has special influence. > > > Which is also something that new would-be corporate > > contributors should know about. > > Yes. All of this would be worthy of a FAQ somewhere. Up for it? I am working on one based on my original statement that started this thread. Witht this dicussion, it has move to the top of my TODO list. -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
On Mon, 2 May 2005, Joshua D. Drake wrote: The issue is that we have had to wack around the existing PL languages for almost every release to make them work with server changes, and being outside our CVS, plPHP isn't getting that whacking. And the point is, as Tom has pointed out with tsearch2, that even *in* CVS, it is a fair amount of work to 'whack' other ppls code ... it shouldn't be Tom's responsibility (which is generally what it comes down to) to keep someone else's code up to speed with changes in the server ... Well we try to keep up :) I'm not pointing fingers at you either :) But, you are one of how many that try and get 'added to core'? How many things do we have in contrib that the only person that does any 'whacking' is Tom? A couple I've seen patches go around for, but for a good portion of them, I imagine that they are 'dead except that Tom keeps fixing them' ... Tom's focus shouldn't be making sure that everyone's third party add on "still works" during a release cycle, that should be the responsibility of the maintainers of those projects, to follow changes and make sure they are implemented ... That is what pgFoundry was setup for ... to give projects the visibiilty they would get through the core distribution by making sure they are referenced in a central place, but providing the maintainers with direct CVS access to make changes to their code in a timely manner .. *shrug* Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
"Marc G. Fournier" <[EMAIL PROTECTED]> writes: > On Mon, 2 May 2005, Bruce Momjian wrote: >> Marc G. Fournier wrote: >>> Then what is the point of having it in CVS? Other then to make are tar >>> ball bigger? >> >> So it can be maintained with other PL languages as the internal API >> changes. This is the same reason ecpg is in our CVS because it is tied >> to the grammar. > Since when? I thought you didn't need the PostgreSQL sources in order to > compile pl/PHP, only the installed headers/libraries ... Joshua, has > something changed, or did I mis-understand that requirement? That could be said of *any* of our PLs (at least now that we install all server-side headers by default ;-)). I think the real reason we keep pltcl etc in the core CVS is exactly what Bruce said: it's easier to maintain 'em that way. The problem is that the PLs use all sorts of internal backend APIs that we don't want to freeze, and so they are constantly being affected by changes in the core backend. Just look at the CVS logs for evidence. Personally, I'm willing to fix the PLs whenever I make a change that affects them, but only if they're in core CVS. Dealing with parallel changes in two different code repositories is too much of a pain. So the folks maintaining non-core PLs take a big hit every release when they have to sync with what's happened in the core backend meanwhile. regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [pgsql-advocacy] [HACKERS] Decision Process WAS: Increased company involvement
Dave, > Well, I never said that core runs around saving the world. I > mostly made the point that core developers have special > influence, Yep. Absolutely. I wanted to point out to you that core isn't the only group within PostgreSQL that has special influence. > Which is also something that new would-be corporate > contributors should know about. Yes. All of this would be worthy of a FAQ somewhere. Up for it? > It is bad if the person > making the proposal doesn't feel he/she has good odds in > defending the proposal and gives up without a fight. Yes.Again, I think a FAQ would help. If people are prepared for the idea of defending their ideas, then they're less likely to quit as soon as someone says "no". > My point is that it's not *democratic*, > and that outsiders wishing to contribute should understand > the dynamic of the process that is not explicitly and officially > spelled out anywhere. Hmmm. We'll there's two (or more) uses of the word "democratic"; so I think there's considerable confusion resulting. In the sense of "democratic" meaning "maximizing the participation and authority of all project members", we are "democratic". In the sense of "one person, one vote", we are not. Classically, our structure could be described as "anarchistic" -- in the 1890's definition, not the modern one. > Right. I agree. I'm not criticising the process as a whole, > and I've more or less made this exact point myself. Yes. I'm not responding just to you, btw. I'm responding to a number of comments from other people who erroneously see Core as exercising more authority than we actually do. > Which may be true philosophically, but in practice, most people > who contribute will not have the resources or motivation to > become a major contributor. I do not mean to imply that this > is necessarily a bad thing; but I think it is the true state of > affairs, and part of the dynamic which must be understood by > someone considering investing in Postgres as a contributor. Certainly. Although the decision-making process for acceptance is really of interest primarily for contributors; that is, if you are not submitting, even by proxy, it shouldn't really matter to you how stuff gets accepted. Except to the extent that you *should* jump in and advocate for proposals by others which you like so that the contributors, committers, and core know what people care about. > That actually doesn't make it more democratic. In a democracy, > everyone has an equal vote regardless of their status. The point > is that a democracy is not always a priori the best form of > organization. Certainly. See above. > What you describe is actually a meritocracy, > and for a project like Postgres, it makes a lot of sense. Hmmm ... I dislike the word "meritocracy" because it is applied equally to corporations, where regardless of merit you're never going to be on the Board. > But > that merely reinforces my point that contributors need to > understand that if their pet feature they create is not in line > with core thinking, they will have to earn the credibility to > get community buy-in. Substitute "major contributors" for "core", and you have *my* buy-in. -- --Josh Josh Berkus Aglio Database Solutions San Francisco ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [pgsql-advocacy] [HACKERS] Decision Process WAS: Increased company
Dave Held wrote: [...] (P.S. on a complete tangent, "call a spade a spade" is actually a racist expression originating in the reconstruction-era South. "spade" does not mean garden tool but is a derogatory slang term for black people. [...] Interesting. Duly noted. It would be interesting if it were true. Be careful the urban myths you accept. See for more info: http://www.randomhouse.com/wotd/index.pperl?date=19970115 Use of the phrase is unwise these days because of the widespread misconception about its origin. PC bites us all. cheers andrew ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
The issue is that we have had to wack around the existing PL languages for almost every release to make them work with server changes, and being outside our CVS, plPHP isn't getting that whacking. And the point is, as Tom has pointed out with tsearch2, that even *in* CVS, it is a fair amount of work to 'whack' other ppls code ... it shouldn't be Tom's responsibility (which is generally what it comes down to) to keep someone else's code up to speed with changes in the server ... Well we try to keep up :) Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 -- Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240 PostgreSQL Replication, Consulting, Custom Programming, 24x7 support Managed Services, Shared and Dedication Hosting Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/ ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
On Mon, 2 May 2005, Bruce Momjian wrote: Marc G. Fournier wrote: On Mon, 2 May 2005, Bruce Momjian wrote: Marc G. Fournier wrote: On Mon, 2 May 2005, Bruce Momjian wrote: I posted this compromise and no one replied so I thought everyone was OK with it. It gets it into CVS, but has a separate compile stage to deal with the recursive dependency problem. Then what is the point of having it in CVS? Other then to make are tar ball bigger? So it can be maintained with other PL languages as the internal API changes. This is the same reason ecpg is in our CVS because it is tied to the grammar. Since when? I thought you didn't need the PostgreSQL sources in order to compile pl/PHP, only the installed headers/libraries ... Joshua, has something changed, or did I mis-understand that requirement? The issue is that we have had to wack around the existing PL languages for almost every release to make them work with server changes, and being outside our CVS, plPHP isn't getting that whacking. And the point is, as Tom has pointed out with tsearch2, that even *in* CVS, it is a fair amount of work to 'whack' other ppls code ... it shouldn't be Tom's responsibility (which is generally what it comes down to) to keep someone else's code up to speed with changes in the server ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(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: [pgsql-advocacy] [HACKERS] Increased company involvement
Since when? I thought you didn't need the PostgreSQL sources in order to compile pl/PHP, only the installed headers/libraries ... Joshua, has something changed, or did I mis-understand that requirement? Well we don't modify the backend or anything but the way plPHP is written it assumes it is part of the tree, which is why we have to patch. However I think part of the argument goes to API. For example the latest release of plPHP will not work with 7.4. Sincerely, Joshua D. Drake Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 -- Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240 PostgreSQL Replication, Consulting, Custom Programming, 24x7 support Managed Services, Shared and Dedication Hosting Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/ ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
On Mon, 2 May 2005, Bruce Momjian wrote: Marc G. Fournier wrote: On Mon, 2 May 2005, Bruce Momjian wrote: I posted this compromise and no one replied so I thought everyone was OK with it. It gets it into CVS, but has a separate compile stage to deal with the recursive dependency problem. Then what is the point of having it in CVS? Other then to make are tar ball bigger? So it can be maintained with other PL languages as the internal API changes. This is the same reason ecpg is in our CVS because it is tied to the grammar. Since when? I thought you didn't need the PostgreSQL sources in order to compile pl/PHP, only the installed headers/libraries ... Joshua, has something changed, or did I mis-understand that requirement? Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
Marc G. Fournier wrote: > On Mon, 2 May 2005, Bruce Momjian wrote: > > > Marc G. Fournier wrote: > >> On Mon, 2 May 2005, Bruce Momjian wrote: > >> > >>> I posted this compromise and no one replied so I thought everyone was OK > >>> with it. It gets it into CVS, but has a separate compile stage to deal > >>> with the recursive dependency problem. > >> > >> Then what is the point of having it in CVS? Other then to make are tar > >> ball bigger? > > > > So it can be maintained with other PL languages as the internal API > > changes. This is the same reason ecpg is in our CVS because it is tied > > to the grammar. > > Since when? I thought you didn't need the PostgreSQL sources in order to > compile pl/PHP, only the installed headers/libraries ... Joshua, has > something changed, or did I mis-understand that requirement? The issue is that we have had to wack around the existing PL languages for almost every release to make them work with server changes, and being outside our CVS, plPHP isn't getting that whacking. -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [pgsql-advocacy] [HACKERS] Decision Process WAS: Increased company involvement
Josh Berkus writes: > As you've already observed, if Tom doesn't like something it's very unlikely > to get through. I lose my share of arguments --- in fact, in the twenty minutes since your posting I already notice Bruce committing a patch I had objected to ;-). Our process is not "democratic" in the sense of any random subscriber to the mailing lists having the same vote as a core member --- and I'll bet Boost doesn't run things that way either. What we have is pretty informal but I think it effectively gives more weight to the opinions of those more involved in the project; which seems a good way to operate. But there isn't anyone here who has an absolute veto, nor contrarily anyone who can force things in unilaterally over strong objections. > [ much good commentary snipped ] regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [pgsql-advocacy] [HACKERS] Decision Process WAS: Increased company involvement
Bruce, > > (P.S. on a complete tangent, "call a spade a spade" is actually a racist > > expression originating in the reconstruction-era South. "spade" does > > You must be from California. :-) Well, yes. Actually, from San Francisco, which is even worse.And I just spent the weekend in Orange County which really gotten my PC dander up. Sorry, Dave! -- --Josh Josh Berkus Aglio Database Solutions San Francisco ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
On Mon, 2 May 2005, Bruce Momjian wrote: I posted this compromise and no one replied so I thought everyone was OK with it. It gets it into CVS, but has a separate compile stage to deal with the recursive dependency problem. Then what is the point of having it in CVS? Other then to make are tar ball bigger? Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [pgsql-advocacy] [HACKERS] Decision Process WAS: Increased company involvement
> -Original Message- > From: Josh Berkus [mailto:[EMAIL PROTECTED] > Sent: Monday, May 02, 2005 1:21 PM > To: Bruce Momjian > Cc: Marc G. Fournier; PostgreSQL advocacy; Dave Held; > PostgreSQL-development > Subject: Re: [pgsql-advocacy] [HACKERS] Decision Process WAS: > Increased > company involvement > > [...] > Hmmm ... why does everyone assume that Core does more than > what we do? I think that most people would be surprised by > how *little* traffic there is on the pgsql-core mailing list. Well, I never said that core runs around saving the world. I mostly made the point that core developers have special influence, and that should be considered when contributing to Postgres, which is directly relevant to the point of the thread, which was originally called "Increased company involvement." > Core decides on releases, and approves committers. > Occasionally we'll handle something which requires > confidentiality, like a security issue or a new > corporate participant. Which is also something that new would-be corporate contributors should know about. > [...] > Materially, what's accepted is decided through open > discussion on the pgsql-hackers list; even Tom brings > up his patches for discussion before commit, and I'd > defy you to point to even one patch which was accepted > by consensus on pgsql-hackers and not committed. But this misses the point. The point is that consensus is often an iterative process, and even if a few people support an idea at first, in the end, the weight of a few "inner circle" people (whether they be core or patch approvers or whatnot) tends to sway the consensus in a certain direction. This isn't always bad, especially if those core people simply know more about the internals of Postgres to have better judgement. It is bad if the person making the proposal doesn't feel he/she has good odds in defending the proposal and gives up without a fight. > As you've already observed, if Tom doesn't like something > it's very unlikely to get through.But that's true for > a lot of major contributors; the consensus process we use > provides ample opportunities to veto and slender > opportunities to pass. This also misses another point. I'm not saying that the current process is inherently flawed. It's probably about as good as any OSS project. My point is that it's not *democratic*, and that outsiders wishing to contribute should understand the dynamic of the process that is not explicitly and officially spelled out anywhere. > [...] > From my perspective, this is a good thing for a database > system which can get easily broken by an ill-considered > patch. It's *good* for us to be development-conservative. Right. I agree. I'm not criticising the process as a whole, and I've more or less made this exact point myself. > So there is an "insider group", but it's the group of major > contributors. That is exactly my point, but you said it better. > Tom has the loudest voice because he writes the most code. > The fact that Tom, Bruce or Peter's veto is often as far as > a proposal goes is simply because most of the pgsql-hackers > subscribers simply don't involve themselves in the process > unless it's one of their own pet features. Which is perfectly understandable. You can probaby guess that most people who use Postgres haven't tried to implement an RDBMS themselves, and have only a shallow understanding of the details. > And the important thing about the group of major contributors > is that membership is open. Which may be true philosophically, but in practice, most people who contribute will not have the resources or motivation to become a major contributor. I do not mean to imply that this is necessarily a bad thing; but I think it is the true state of affairs, and part of the dynamic which must be understood by someone considering investing in Postgres as a contributor. > [...] > If people want the acceptance process to be more "democratic", > then those people have to be willing to do the work of full > participation. That actually doesn't make it more democratic. In a democracy, everyone has an equal vote regardless of their status. The point is that a democracy is not always a priori the best form of organization. What you describe is actually a meritocracy, and for a project like Postgres, it makes a lot of sense. But that merely reinforces my point that contributors need to understand that if their pet feature they create is not in line with core thinking, they will have to earn the credibility to get community buy-in. > [...] > (P.S. on a complete tangent, "call a spade a spade" is > actually a racist expression originating in the > reconstruction-era South. "spade" does not mean garden tool > but is a derogatory slang term for black people. > [...] Interesting. Duly noted. __ David B. Held Software Engineer/Array Services Group 200 14th Ave. East, Sartell, MN 56377 320.534.3637 320.253.7800 800.7
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
Marc G. Fournier wrote: > On Mon, 2 May 2005, Bruce Momjian wrote: > > > I posted this compromise and no one replied so I thought everyone was OK > > with it. It gets it into CVS, but has a separate compile stage to deal > > with the recursive dependency problem. > > Then what is the point of having it in CVS? Other then to make are tar > ball bigger? So it can be maintained with other PL languages as the internal API changes. This is the same reason ecpg is in our CVS because it is tied to the grammar. -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [pgsql-advocacy] [HACKERS] Decision Process WAS: Increased
On Mon, 2 May 2005, Josh Berkus wrote: As you've already observed, if Tom doesn't like something it's very unlikely to get through. One thing to note on this one ... I've never seen Tom *not* try and help the submitter to get the code up to spec either ... he's always bent over backwards to try and help set someone on the right path if the patch submission warrants it ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [pgsql-advocacy] [HACKERS] Decision Process WAS: Increased
Marc G. Fournier wrote: On Mon, 2 May 2005, Josh Berkus wrote: As you've already observed, if Tom doesn't like something it's very unlikely to get through. One thing to note on this one ... I've never seen Tom *not* try and help the submitter to get the code up to spec either ... he's always bent over backwards to try and help set someone on the right path if the patch submission warrants it ... I would second this. Even when he has disagreed he is always willing to say why and even offer guidance to sway him. Sincerely, Joshua D. Drake Command Prompt, Inc. Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster -- Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240 PostgreSQL Replication, Consulting, Custom Programming, 24x7 support Managed Services, Shared and Dedication Hosting Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/ ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] pg_locks needs a facelift
"Merlin Moncure" <[EMAIL PROTECTED]> writes: >> "Merlin Moncure" <[EMAIL PROTECTED]> writes: >> Fair enough, although I think that at least one major application of >> user locks would be equivalent to tuple locks. Somebody was asking >> for named user locks in the previous thread, and the easiest way to >> get that is to make a table containing just lock names, and then lock >> on the CTIDs of that table. Since there would be no reason to allow >> UPDATE or DELETE in such a table, the putative instability of CTID >> doesn't really matter. > This is fine, but relying on structures outside of shared memory is a > fairly hefty price. User locks are very fast and tight and incur zero > maintenance overhead...with a table you have to consider vacuuming > strategies + possible reindex for the unique constraint...bleh. What vacuuming strategy? It's a constant table, at least in my view of the usage. I see no reason for the table lookups to be part of the performance critical path, either --- if you're grabbing and releasing a particular lock a lot, you could read the needed CTID and cache it on the application side. In any case, we are certainly *not* expanding LOCKTAG to the point where it can hold random user-defined strings ;-) > I also wonder if there would be a race condition if someone tried to > acquire ctid based named lock at the same time a user lock with the same > value, unless ctid locks were maintained in a separate hash table. This would be a matter of making sure you didn't use conflicting LOCKTAG bit patterns for different purposes. In practice the easiest way to do that would be to add more LockTagType enum values, which is trivial enough now. (I'll probably fix pg_locks so that if it doesn't recognize a particular LockTagType value, it prints the locktag as the numeric value of the tag, rather than falling back to something unhelpful like "unknown". This way you could make some use of freshly-invented tag values without any changes at all in the core backend.) > well, the old ones are GPL. I've made a few attempts to contact the > original author...he's MIA. Since 95% of the implementation is in the > backend, it seems odd to have a GPL interface. I agree. Wasn't it you that was proposing to rewrite the module from scratch to eliminate the GPL restriction? regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Feature freeze date for 8.1
On 2005-05-02, Tom Lane <[EMAIL PROTECTED]> wrote: > While that isn't an unreasonable issue on its face, I think it really > boils down to this: the OP is complaining because he thinks the > connection-loss timeout mandated by the TCP RFCs is too long. Perhaps > the OP knows network engineering far better than the authors of those > RFCs, or perhaps not. I'm not convinced that Postgres ought to provide > a way to second-guess the TCP stack ... Speaking as someone who _does_ know network engineering, I would say that yes, Postgres absolutely should do so. The TCP keepalive timeout _is not intended_ to do this job; virtually every application-level protocol manages its own timeouts independently of TCP. (The few exceptions, such as telnet, tend to be purely interactive protocols that rely on the user to figure out that something got stuck.) One way to handle this is to have an option, set by the client, that causes the server to send some ignorable message after a given period of time idle while waiting for the client. If the idleness was due to network partitioning or similar failure, then this ensures that the connection breaks within a known time. This is safer than simply having the backend abort after a given idle period. If you want comparisons from other protocols, just look around - SMTP, ssh, IRC, BGP, NNTP, FTP, and many, many more protocols all use timeouts (or in some cases keepalive messages) with intervals much shorter than the TCP keepalive timeout itself. -- Andrew, Supernews http://www.supernews.com - individual and corporate NNTP services ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [pgsql-advocacy] [HACKERS] Decision Process WAS: Increased company involvement
Dave, > The group has moderators, but they exist only > to moderate discussion on the mailing lists. I'm not saying that > it is bad that Postgres is not democratic. Postgres is a totally > different kind of beast than Boost, and probably benefits from > having a few people ultimately decide its fate. But let's call a > spade a spade and not pretend that contributors don't have to get > buy-in from core. Hmmm ... why does everyone assume that Core does more than what we do? I think that most people would be surprised by how *little* traffic there is on the pgsql-core mailing list. Core decides on releases, and approves committers. Occasionally we'll handle something which requires confidentiality, like a security issue or a new corporate participant. The committers, who do *not* have exact overlap with Core (for example, Neil is a committer but not on Core, and I am on Core but not a committer) actually commit patches, so the participation of *one* of them is required to get something in to the core code. Materially, what's accepted is decided through open discussion on the pgsql-hackers list; even Tom brings up his patches for discussion before commit, and I'd defy you to point to even one patch which was accepted by consensus on pgsql-hackers and not committed. As you've already observed, if Tom doesn't like something it's very unlikely to get through.But that's true for a lot of major contributors; the consensus process we use provides ample opportunities to veto and slender opportunities to pass. Go back in the archives to 7.4 development, and you will see Peter exercising his veto a lot, rather than Tom -- and Peter was not a Core team member at the time. From my perspective, this is a good thing for a database system which can get easily broken by an ill-considered patch. It's *good* for us to be development-conservative. So there is an "insider group", but it's the group of major contributors. Tom has the loudest voice because he writes the most code. The fact that Tom, Bruce or Peter's veto is often as far as a proposal goes is simply because most of the pgsql-hackers subscribers simply don't involve themselves in the process unless it's one of their own pet features. And the important thing about the group of major contributors is that membership is open. This goes beyond new proposals. Just the other day Bruce was lamenting the fact that despite having a number of committers, nobody other than him seems willing to work out the conflicts and get pending patches into acceptable shape for backend integration -- some patches stayed in the queue for months while he was out.This is bad; it bottlenecks us and makes Bruce and Tom the de-facto arbiters of acceptance because they personally have to adjust and commit submissions. If people want the acceptance process to be more "democratic", then those people have to be willing to do the work of full participation. This means arguing and doing research on the hackers list, even for proposals that don't personally benefit you; helping debug and/or test patches to get rid of their problems; and ultimately, becoming a major contributor and then a committer yourself so that you can take over part of Bruce's workload. When this system has broken down it's specifically because people on the -hackers list were lazy or distracted and ignored other people's patch proposals, allowing one member's (whether Tom or anyone else) reflexive veto to stand without challenge. And by failing to champion the usefulness of proposals. I know that some of Joe's proposals were unfairly killed simply because nobody on -hackers spoke up for them, leading Tom and others to believe that they weren't popular or needed. Personally, I tend to think that one of the several things fundamentally broken in the US electoral system is that there is no relationship between political participation, voting, and authority. I don't see any reason to replicate those mistakes with our project.So if your definition of "democracy" is "everyone has an equal voice regardless of participation level", then thank the gods we're not a "democracy". (P.S. on a complete tangent, "call a spade a spade" is actually a racist expression originating in the reconstruction-era South. "spade" does not mean garden tool but is a derogatory slang term for black people. It's an expression I avoid for that reason. I don't expect anyone to have known this, but now you do.) -- --Josh Josh Berkus Aglio Database Solutions San Francisco ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
On Mon, 2 May 2005, Bruce Momjian wrote: Joshua D. Drake wrote: Well, I think there's numerous examples where someone suggests some feature or idea, and Tom or one or two other core developers will say: "I don't like that idea", and then the proposer will more or less give up on it because it is clear that it won't go anywhere. Well I think that is more perception than anything. Sometimes you have to fight for what you believe in. For example plPHP. I believe plPHP belongs in core as do some other people. There are members of core that are for it and against it. Command Prompt as the submitter needs to make a valid argument to sway core. We need to present code they would be happy with. We need to present reasons why. I think the plan for plphp is to put the source in our CVS, but to require it to be compiled as a separate 'make' step after php is fully installed and using the new libpq. I think we had agreement on that solution. Last I read, both Tom and I were against it being in CVS (albeit for different reasons) ... and there hadn't been any discussions past the end of that thread that I've seen ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
Marc G. Fournier wrote: > On Mon, 2 May 2005, Bruce Momjian wrote: > > > Joshua D. Drake wrote: > >>> > >>> Well, I think there's numerous examples where someone suggests some > >>> feature or idea, and Tom or one or two other core developers will > >>> say: "I don't like that idea", and then the proposer will more or > >>> less give up on it because it is clear that it won't go anywhere. > >> > >> Well I think that is more perception than anything. Sometimes you have > >> to fight for what you believe in. For example plPHP. I believe plPHP > >> belongs in core as do some other people. There are members of core > >> that are for it and against it. > >> > >> Command Prompt as the submitter needs to make a valid argument to sway > >> core. We need to present code they would be happy with. We need to > >> present reasons why. > > > > I think the plan for plphp is to put the source in our CVS, but to > > require it to be compiled as a separate 'make' step after php is fully > > installed and using the new libpq. I think we had agreement on that > > solution. > > Last I read, both Tom and I were against it being in CVS (albeit for > different reasons) ... and there hadn't been any discussions past the end > of that thread that I've seen ... I posted this compromise and no one replied so I thought everyone was OK with it. It gets it into CVS, but has a separate compile stage to deal with the recursive dependency problem. -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(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] pg_locks needs a facelift
> "Merlin Moncure" <[EMAIL PROTECTED]> writes: > Fair enough, although I think that at least one major application of > user locks would be equivalent to tuple locks. Somebody was asking > for named user locks in the previous thread, and the easiest way to > get that is to make a table containing just lock names, and then lock > on the CTIDs of that table. Since there would be no reason to allow > UPDATE or DELETE in such a table, the putative instability of CTID > doesn't really matter. This is fine, but relying on structures outside of shared memory is a fairly hefty price. User locks are very fast and tight and incur zero maintenance overhead...with a table you have to consider vacuuming strategies + possible reindex for the unique constraint...bleh. If the lock table was not synced and auto-vacuumed, then maybe it could work. I also wonder if there would be a race condition if someone tried to acquire ctid based named lock at the same time a user lock with the same value, unless ctid locks were maintained in a separate hash table. Interesting aside: you can get very similar functionality by abusing pg_listener...not that I'd suggest doing that however ;). > Certainly the current contrib/userlock code could stand a rewrite. > Or more likely, addition of new functions --- we should deprecate > the old ones, but I see no need to remove 'em right away. well, the old ones are GPL. I've made a few attempts to contact the original author...he's MIA. Since 95% of the implementation is in the backend, it seems odd to have a GPL interface. Merlin ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
pgman wrote: > > If you don't do that, then yes I can see why it would feel as if > > the proposer was at a loss once someone like Tom writes his opinion. > > > > However Tom isn't the final word, he just happens to have a lot of > > weight as anyone within the project of good standing who donates as much > > as he does would. > > > > Everything within the community is pretty much done as a vote and there > > are things that core really has nothing to do with (like pgFoundry). > > Right, the point is that Tom has weight because he is Tom and people > value his opinion, not because he is core. It seems that though discerning observers agree with the above statement, the perception of new people is that Tom has weight _mostly_ because he is in core. So, how do we fix this? Do we boot Tom out of core so people can see he has the same impact? That seems pointless. (Funny, no one says I have too much power. I will have to look into how to get some someday.) :-) -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
Dave Held wrote: > Just watching the hackers list suggests to me that this is the norm, > rather than the exception. I guess I'm interested to see which > patches have been accepted that the core developers opposed. Now > don't get me wrong. Sometimes there are good technical reasons why > feature A or B can't or shouldn't be added or even developed. And > I don't suggest that patches lacking technical merit should not be > rejected. But sometimes it seems that ideas with undetermined > merit get passed over because of a quick judgement based on > intuition, and only if the proposer actively fights for it for a > while does it get reconsidered. > > Of course, it would be quite a bit of work for me to review the > list and compile instances where I think this has occurred, but > only because of the tedium involved to make a minor point...not > because I think I would have difficulty finding evidence. I'm just Well, if there was an issue and you had been around for a minimal amount of time, I would think you could come up with at least one example. > saying that as an outsider, if I had a lot of resources to devote > to contributing to Postgres, I would only consider working on > approved TODO items or making sure I more or less had core buy-in > before writing any code. I don't think it would be worth my > time to work on something that non-core users/developers might > like but core hackers don't. Well, our developer's FAQ clearly states you should communicate your ideas to the hackers list before starting work to be sure you have _community_ buy-in, rather than core buy-in. And the TODO list is not a core list, it is accumulated from community suggestions and discussion. > Like I said, that's not necessarily a bad thing. Postgres is a > piece of software with many interacting components, and there > needs to be some coordination to make sure it evolves in a > sensible way. But I think that implies that there must be and > is some de facto centralization of control, whether that is the > published ideology or not. I will give you the example of adding a read-only table as an example. I am betting the idea will not be accepted because the costs outweight the gain, but I will post my opinions on the list and others will as well and we will come to some concensus. If X members feel something is bad, and 5X members think something is good, it almost always gets in --- it doesn't matter if all the core people are in X or not. Another example is the recent patch to check if there are orphaned file system files. That was submitted, Tom had questions, I posted why I thought it was valid, and the patch is going in today. Anyone has the ability to argue their point and try to sway the community, and any member has the right to request a vote on a specific issue. Perhaps we are more a replublic because we do defer our judgement to others who have looked into the area more thoroughly. -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
Joshua D. Drake wrote: > > > > Well, I think there's numerous examples where someone suggests some > > feature or idea, and Tom or one or two other core developers will > > say: "I don't like that idea", and then the proposer will more or > > less give up on it because it is clear that it won't go anywhere. > > Well I think that is more perception than anything. Sometimes you have > to fight for what you believe in. For example plPHP. I believe plPHP > belongs in core as do some other people. There are members of core > that are for it and against it. > > Command Prompt as the submitter needs to make a valid argument to sway > core. We need to present code they would be happy with. We need to > present reasons why. I think the plan for plphp is to put the source in our CVS, but to require it to be compiled as a separate 'make' step after php is fully installed and using the new libpq. I think we had agreement on that solution. > If you don't do that, then yes I can see why it would feel as if > the proposer was at a loss once someone like Tom writes his opinion. > > However Tom isn't the final word, he just happens to have a lot of > weight as anyone within the project of good standing who donates as much > as he does would. > > Everything within the community is pretty much done as a vote and there > are things that core really has nothing to do with (like pgFoundry). Right, the point is that Tom has weight because he is Tom and people value his opinion, not because he is core. -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
Any person can bring a patch and submit it, any person in the community can argue for it and any person can take the time to fix it to the specifications that core sets forth. True, but I don't think "core" sets the specifications. Rather, it is the community that sets them, or agrees to them by not saying anything. Well I can't concur with that. I can concur that may be what "core" would want but I don't see that as what it is. However that could could also be perception as it isn't really that clear what core does except set the specification. Sincerely, Joshua D. Drake Command Prompt, Inc. -- Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240 PostgreSQL Replication, Consulting, Custom Programming, 24x7 support Managed Services, Shared and Dedication Hosting Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/ ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] pg_locks needs a facelift
> > A properly implemented user lock system would likely > > maintain a global sequence shared by all lockable objects, tuple or > > otherwise. > > That'd just be equivalent to require that user tables are created WITH > OIDS, only the counter wouldn't be shared with system tables ... how is > that any better? Well, oid is 32 bit and not guaranteed to be unique...therefore useless. However by properly defined, I meant by the application. The server is agnostic about user locks, a.k.a. 'application defined locks'. Merlin ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
> -Original Message- > From: Joshua D. Drake [mailto:[EMAIL PROTECTED] > Sent: Monday, May 02, 2005 12:33 PM > To: Dave Held > Cc: PostgreSQL-development; PostgreSQL advocacy > Subject: Re: [pgsql-advocacy] [HACKERS] Increased company involvement > > [...] > PostgreSQL is more of Democratic Republic than an actual > democracy but they do very well at it. I buy that. It is probably a fairly accurate description of the Postgres community. Everyone has a voice, but ultimately, the "Senate" (i.e.: patch approvers) passes the laws. Where it differs is that the Senate is not necessarily democratically elected. ;) > Any person can bring a patch and submit it, any person in the > community can argue for it and any person can take the time to > fix it to the specifications that core sets forth. Which brings up an important point. The core developers define the structure in which change can occur. If people think that Postgres should move in a direction that affects that framework, they have to convince core to redefine that specification. It's like writing new laws vs. amending the Constitution. Even though anyone can draft a bill and submit it to their representative, it's ultimately Congress that makes the laws. And while public opinion can ultimately affect the actions of Congress, it is still a sovereign body. As Bruce himself said, companies that wish to contribute must not assume that their work will be integrated into Postgres. The official stance is that there only needs to be community buy-in, but it seems more realistic that there needs to be core buy-in as well, at the least because of the influence that core thinking has on the community itself. That's not a bad thing per se, but it's definitely something that contributors should consider. __ David B. Held Software Engineer/Array Services Group 200 14th Ave. East, Sartell, MN 56377 320.534.3637 320.253.7800 800.752.8129 ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
Joshua D. Drake wrote: > > >>We don't want core to steer development anymore than we want a > >>centralized group to do that, because if we did, the next company > >>that comes along and wants to enhance PostgreSQL or offer technical > >>support services will feel they have to get approval/buy-in from > >>the _in_ group, and that isn't a productive setup. The fact that > >>new companies getting involved can't find a central authority is a > >>_good_ thing, if you think about it. It means that we have succeeded > >>in building a community that allows people to join and feel a part > >>right away, and they don't have to buy-in or play politics to do it. > > > > > > Well, you make Postgres sound like a very democratic community, but > > I'm afraid this is a fairy tale. Aren't the people who approve > > patches exactly the in group that you claim doesn't exist? > > PostgreSQL is more of Democratic Republic than an actual democracy but > they do very well at it. > > Any person can bring a patch and submit it, any person in the community > can argue for it and any person can take the time to fix it to the > specifications that core sets forth. True, but I don't think "core" sets the specifications. Rather, it is the community that sets them, or agrees to them by not saying anything. -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(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: [pgsql-advocacy] [HACKERS] Increased company involvement
Well, I think there's numerous examples where someone suggests some feature or idea, and Tom or one or two other core developers will say: "I don't like that idea", and then the proposer will more or less give up on it because it is clear that it won't go anywhere. Well I think that is more perception than anything. Sometimes you have to fight for what you believe in. For example plPHP. I believe plPHP belongs in core as do some other people. There are members of core that are for it and against it. Command Prompt as the submitter needs to make a valid argument to sway core. We need to present code they would be happy with. We need to present reasons why. If you don't do that, then yes I can see why it would feel as if the proposer was at a loss once someone like Tom writes his opinion. However Tom isn't the final word, he just happens to have a lot of weight as anyone within the project of good standing who donates as much as he does would. Everything within the community is pretty much done as a vote and there are things that core really has nothing to do with (like pgFoundry). Sincerely, Joshua D. Drake Command Prompt, Inc. -- Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240 PostgreSQL Replication, Consulting, Custom Programming, 24x7 support Managed Services, Shared and Dedication Hosting Co-Authors: plPHP, plPerlNG - http://www.commandprompt.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: [pgsql-advocacy] [HACKERS] Increased company involvement
> -Original Message- > From: Bruce Momjian [mailto:[EMAIL PROTECTED] > Sent: Monday, May 02, 2005 12:17 PM > To: PostgreSQL advocacy > Cc: Dave Held; PostgreSQL-development > Subject: Re: [pgsql-advocacy] [HACKERS] Increased company involvement > > > [...] > > Really? You have a different perspective than I see. I have > > seen patches be accepted that had no core buy-in. We accept > > patches based on group feedback, not some closed approval > > process. > > Let me also ask for you to provide an example of the behavior you > describe. Well, I think there's numerous examples where someone suggests some feature or idea, and Tom or one or two other core developers will say: "I don't like that idea", and then the proposer will more or less give up on it because it is clear that it won't go anywhere. So whether the process gets stopped at the patch submission level or the feature proposal level isn't really relevant. It seems pretty clear that a handful of people decide the direction of Postgres, and everyone else can either contribute to the features that have been agreed to be acceptable and relevant, or they can fork their own version. Just watching the hackers list suggests to me that this is the norm, rather than the exception. I guess I'm interested to see which patches have been accepted that the core developers opposed. Now don't get me wrong. Sometimes there are good technical reasons why feature A or B can't or shouldn't be added or even developed. And I don't suggest that patches lacking technical merit should not be rejected. But sometimes it seems that ideas with undetermined merit get passed over because of a quick judgement based on intuition, and only if the proposer actively fights for it for a while does it get reconsidered. Of course, it would be quite a bit of work for me to review the list and compile instances where I think this has occurred, but only because of the tedium involved to make a minor point...not because I think I would have difficulty finding evidence. I'm just saying that as an outsider, if I had a lot of resources to devote to contributing to Postgres, I would only consider working on approved TODO items or making sure I more or less had core buy-in before writing any code. I don't think it would be worth my time to work on something that non-core users/developers might like but core hackers don't. Like I said, that's not necessarily a bad thing. Postgres is a piece of software with many interacting components, and there needs to be some coordination to make sure it evolves in a sensible way. But I think that implies that there must be and is some de facto centralization of control, whether that is the published ideology or not. __ David B. Held Software Engineer/Array Services Group 200 14th Ave. East, Sartell, MN 56377 320.534.3637 320.253.7800 800.752.8129 ---(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] Citation for "Bad n_distinct estimation; hacks suggested?"
Actually, the earliest paper that solves the distinct_n estimation problem in 1 pass is the following: "Estimating simple functions on the union of data streams" by Gibbons and Tirthapura, SPAA 2001. http://home.eng.iastate.edu/~snt/research/streaming.pdf The above paper addresses a more difficult problem (1 pass _and_ a distributed setting). Gibbon's followup paper in VLDB 2001 limits the problem to a single machine and contains primarily experimental results (for a database audience). The algorithmic breakthrough had already been accomplished in the SPAA paper. Gurmeet -- Gurmeet Singh Manku Google Inc. http://www.cs.stanford.edu/~manku(650) 967 1890 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
We don't want core to steer development anymore than we want a centralized group to do that, because if we did, the next company that comes along and wants to enhance PostgreSQL or offer technical support services will feel they have to get approval/buy-in from the _in_ group, and that isn't a productive setup. The fact that new companies getting involved can't find a central authority is a _good_ thing, if you think about it. It means that we have succeeded in building a community that allows people to join and feel a part right away, and they don't have to buy-in or play politics to do it. Well, you make Postgres sound like a very democratic community, but I'm afraid this is a fairy tale. Aren't the people who approve patches exactly the in group that you claim doesn't exist? PostgreSQL is more of Democratic Republic than an actual democracy but they do very well at it. Any person can bring a patch and submit it, any person in the community can argue for it and any person can take the time to fix it to the specifications that core sets forth. Sincerely, Joshua D. Drake Command Prompt,Inc. -- Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240 PostgreSQL Replication, Consulting, Custom Programming, 24x7 support Managed Services, Shared and Dedication Hosting Co-Authors: plPHP, plPerlNG - http://www.commandprompt.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: [pgsql-advocacy] [HACKERS] Increased company involvement
Marc G. Fournier wrote: > On Mon, 2 May 2005, Bruce Momjian wrote: > > > Bruce Momjian wrote: > >> Dave Held wrote: > >>> Well, you make Postgres sound like a very democratic community, but > >>> I'm afraid this is a fairy tale. Aren't the people who approve > >>> patches exactly the in group that you claim doesn't exist? Aren't > >>> they the people that you need buy-in from to really contribute to > >>> Postgres? The reason I make this point is because I know what a > >>> democratic development community really looks like, and the Boost > >>> community is one such example. That truly *is* democratic, because > >>> decisions are made as a group, and no fixed subset of members has > >>> an overriding veto. The group has moderators, but they exist only > >>> to moderate discussion on the mailing lists. I'm not saying that > >>> it is bad that Postgres is not democratic. Postgres is a totally > >>> different kind of beast than Boost, and probably benefits from > >>> having a few people ultimately decide its fate. But let's call a > >>> spade a spade and not pretend that contributors don't have to get > >>> buy-in from core. > >> > >> Really? You have a different perspective than I see. I have seen > >> patches be accepted that had no core buy-in. We accept patches based on > >> group feedback, not some closed approval process. > > > > Let me also ask for you to provide an example of the behavior you > > describe. > > How many patches have you "applied" thinking they were good/safe, only to > have Tom jump on top of you and either require changes, or yank them > completely? > > As far as code submissions are concerned, Tom has pretty much been "final > arbitrar" (not that I'm against that, I think its required to keep the > code 'clean') ... those with cvs commit privileges are a bit higher on the > totem, but they've already been "through the fire" with Tom, else they > would't have those privileges ... Tom can bring up issues, but it is up to the group to decide if those are valid. Tom has sway only to the exent the group agrees with Tom's analysis. If someone else made similar observations, they would take similar weight, as soon as we were sure the person was reliable in their observations. Tom gets patches pulled only because his observations are deemed to be right by the group, not because he is Tom. The same holds for pretty much anyone else in the group. -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] pg_locks needs a facelift
"Merlin Moncure" <[EMAIL PROTECTED]> writes: > I don't like the idea of listing user locks with 'tuple' locks for no > other reason than this might confuse what user locks are. Fair enough, although I think that at least one major application of user locks would be equivalent to tuple locks. Somebody was asking for named user locks in the previous thread, and the easiest way to get that is to make a table containing just lock names, and then lock on the CTIDs of that table. Since there would be no reason to allow UPDATE or DELETE in such a table, the putative instability of CTID doesn't really matter. However, displaying them as object locks certainly works, and you'd have to put some intelligence in front of the view anyway about what meaning you were assigning to user locks in your installation. So you can always cast to whatever you need. > IMO, this is a problem with the current user lock module...it > encourages locking over oid which is a bad practice. A properly > implemented user lock system would likely maintain a global sequence > shared by all lockable objects, tuple or otherwise. Certainly the current contrib/userlock code could stand a rewrite. Or more likely, addition of new functions --- we should deprecate the old ones, but I see no need to remove 'em right away. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] pg_locks needs a facelift
On Mon, May 02, 2005 at 01:12:06PM -0400, Merlin Moncure wrote: > I don't like the idea of listing user locks with 'tuple' locks for no > other reason than this might confuse what user locks are. Even though > they will be used as tuple locks 99% of the time, user locks are only > loosely coupled with tuples in part because there is no sytem generated > column which is persistent and > 32 bits. IMO, this is a problem with > the current user lock module...it encourages locking over oid which is a > bad practice. Another way would be to allow user locks to use the four fields of LOCKTAG. So the user would be able to establish more powerful conventions: say the relation's Oid, and a related sequence value if there is one; or a blocknumber/offset (ctid) if there isn't, etc. > A properly implemented user lock system would likely > maintain a global sequence shared by all lockable objects, tuple or > otherwise. That'd just be equivalent to require that user tables are created WITH OIDS, only the counter wouldn't be shared with system tables ... how is that any better? -- Alvaro Herrera (<[EMAIL PROTECTED]>) "Ellos andaban todos desnudos como su madre los parió, y también las mujeres, aunque no vi más que una, harto moza, y todos los que yo vi eran todos mancebos, que ninguno vi de edad de más de XXX años" (Cristóbal Colón) ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
On Mon, 2 May 2005, Bruce Momjian wrote: Bruce Momjian wrote: Dave Held wrote: Well, you make Postgres sound like a very democratic community, but I'm afraid this is a fairy tale. Aren't the people who approve patches exactly the in group that you claim doesn't exist? Aren't they the people that you need buy-in from to really contribute to Postgres? The reason I make this point is because I know what a democratic development community really looks like, and the Boost community is one such example. That truly *is* democratic, because decisions are made as a group, and no fixed subset of members has an overriding veto. The group has moderators, but they exist only to moderate discussion on the mailing lists. I'm not saying that it is bad that Postgres is not democratic. Postgres is a totally different kind of beast than Boost, and probably benefits from having a few people ultimately decide its fate. But let's call a spade a spade and not pretend that contributors don't have to get buy-in from core. Really? You have a different perspective than I see. I have seen patches be accepted that had no core buy-in. We accept patches based on group feedback, not some closed approval process. Let me also ask for you to provide an example of the behavior you describe. How many patches have you "applied" thinking they were good/safe, only to have Tom jump on top of you and either require changes, or yank them completely? As far as code submissions are concerned, Tom has pretty much been "final arbitrar" (not that I'm against that, I think its required to keep the code 'clean') ... those with cvs commit privileges are a bit higher on the totem, but they've already been "through the fire" with Tom, else they would't have those privileges ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Feature freeze date for 8.1
On Mon, 2 May 2005 18:47:14 +0300 (EEST) Heikki Linnakangas <[EMAIL PROTECTED]> wrote: >FWIW, I've been bitten by this problem twice with other >applications. > >1. We had a DB2 database with clients running in other >computers in the network. A faulty switch caused random >network outages. If the connection timed out and the >client was unable to send it's request to the server, the >client would notice that the connection was down, and open >a new one. But the server never noticed that the >connection was dead. Eventually, the maximum number of >connections was reached, and the administrator had to kill >all the connections manually. Are you pleased from this feature on DB2 ? I think you will say no :-) >2. We had a custom client-server application using TCP >across a network. There was stateful firewall between the >server and the clients that dropped the connection at >night when there was no activity. After a couple of days, >the server reached the maximum number of threads on the >platform and stopped accepting new connections. Yes, because your firewall drops only connectiona between clients and firewall, not database. >In case 1, the switch was fixed. If another switch fails, >the same will happen again. In case 2, we added an >application-level heartbeat that sends a dummy message >from server to client every 10 minutes. > >TCP keep-alive with a small interval would have saved the >day in both cases. Unfortunately the default interval must >be >= 2 hours, according to RFC1122. Yes.. >On most platforms, including Windows and Linux, the TCP >keep-alive interval can't be set on a per-connection >basis. The ideal solution would be to modify the operating >system to support it. How will we do this ? >What we can do in PostgreSQL is to introduce an >application-level heartbeat. A simple "Hello world" >message sent from server to client that the client would >ignore would do the trick. This couldnt be not forgetten that a clients can have more than one connection to database and one of them is lost.. Best Regards, Adnan DURSUN ASRIN Bilişim Hiz.Ltd. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] pg_locks needs a facelift
Tom Lane wrote: > > This seems perfectly ok...as long as there is 1:1 correspondence between > > locktag and lock for all present and future types of locks. I'd like to > > point out though that when querying for user locks it's kind of nice not > > to wade through transaction locks, etc. > > Well, sure, but that's what "SELECT ... WHERE" is for ;-) yeah, I misread your earlier post...being able to filter on lock type (or not) is an ideal solution. So, pg_locks it is. I'd also like to make one more comment: > This still leaves us with the issue of what to do with user locks. > I am inclined to display them as if they were OBJECT locks, ie, fill > the database, classid, objid, and objsubid columns. An alternative > that would also expose all the info is to display them as if they > were TUPLE locks. Or we could add still more columns, but I'm not > real enthused about that idea. I don't like the idea of listing user locks with 'tuple' locks for no other reason than this might confuse what user locks are. Even though they will be used as tuple locks 99% of the time, user locks are only loosely coupled with tuples in part because there is no sytem generated column which is persistent and > 32 bits. IMO, this is a problem with the current user lock module...it encourages locking over oid which is a bad practice. A properly implemented user lock system would likely maintain a global sequence shared by all lockable objects, tuple or otherwise. Listing them as object locks seems ok. Merlin ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
Bruce Momjian wrote: > Dave Held wrote: > > Well, you make Postgres sound like a very democratic community, but > > I'm afraid this is a fairy tale. Aren't the people who approve > > patches exactly the in group that you claim doesn't exist? Aren't > > they the people that you need buy-in from to really contribute to > > Postgres? The reason I make this point is because I know what a > > democratic development community really looks like, and the Boost > > community is one such example. That truly *is* democratic, because > > decisions are made as a group, and no fixed subset of members has > > an overriding veto. The group has moderators, but they exist only > > to moderate discussion on the mailing lists. I'm not saying that > > it is bad that Postgres is not democratic. Postgres is a totally > > different kind of beast than Boost, and probably benefits from > > having a few people ultimately decide its fate. But let's call a > > spade a spade and not pretend that contributors don't have to get > > buy-in from core. > > Really? You have a different perspective than I see. I have seen > patches be accepted that had no core buy-in. We accept patches based on > group feedback, not some closed approval process. Let me also ask for you to provide an example of the behavior you describe. -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
Dave Held wrote: > Well, you make Postgres sound like a very democratic community, but > I'm afraid this is a fairy tale. Aren't the people who approve > patches exactly the in group that you claim doesn't exist? Aren't > they the people that you need buy-in from to really contribute to > Postgres? The reason I make this point is because I know what a > democratic development community really looks like, and the Boost > community is one such example. That truly *is* democratic, because > decisions are made as a group, and no fixed subset of members has > an overriding veto. The group has moderators, but they exist only > to moderate discussion on the mailing lists. I'm not saying that > it is bad that Postgres is not democratic. Postgres is a totally > different kind of beast than Boost, and probably benefits from > having a few people ultimately decide its fate. But let's call a > spade a spade and not pretend that contributors don't have to get > buy-in from core. Really? You have a different perspective than I see. I have seen patches be accepted that had no core buy-in. We accept patches based on group feedback, not some closed approval process. -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
