Re: [HACKERS] Call for 7.5 feature completion
On Mon, 17 May 2004, Alvaro Herrera Munoz wrote: On Mon, May 17, 2004 at 04:55:50PM +0200, Zeugswetter Andreas SB SD wrote: Can we try to do the 2PC patch now instead of waiting for subtransactions ? The last post from Heikki I read said that he discovered some serious problems with his implementation and he wanted do rethink about them. I don't think he will be able to make it, mainly because if my patch gets accepted it will be too close to feature freeze (if it is June 1st). That's still the status with my 2PC patch. It works, as long as you don't try to touch system catalogs, use notifications, set session GUC variables or do any other fancy stuff. In those cases you get a not implemented error when you try to prepare the transaction, and the it aborts. I think I figured out the MVCC snapshot issues, but I haven't really tested it so there could be some nasty race conditions I missed. I won't make it to June 1., I'll be on vacation on May 20-27, and I'm quite busy at work at the moment. I'd like to get the patch committed as soon as the 7.6 release cycle begins, with whatever limitations it has at that time. - Heikki ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Call for 7.5 feature completion
That is the plan ... unless someone knows a reason why they can't be built independently of the core? How about this one: Everything we have moved from the core to gborg so far has been a miserable failure. The code is no longer maintained, or maintained by three different competing groups, the documentation has disappeared, the portability is no longer taken care of, and only the bravest souls even dare look at the stuff. I think before you move anything more, you need to have a strong, convincing community on the receiving side rather than just kicking things out and hoping someone will pick it up. Just because it can be built separately doesn't mean everything needs to be. Another thing is how the end user gets to the files. As an end user, you'd generally not care which CVS server the code is on. What you *do* care about is that it's included in the main RPM/DEB or whatever *and* the main source tarball (if I download complete server, I certainly want a complete server. Including for example PLs, which is one of postgresqls strengths..). Same goes for the docs, of course. If it's in main CVS you get the benefit of having it included in the normal release management. Sure, it adds a burden on the release management work, but that job has to be done somewhere. And id you just pull in whatever version happens to be latest and put this in the release version, you are probably in for some nasty surprises. //Magnus ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Call for 7.5 feature completion
a release, etc ... I'd almost say that time would be better spent on coming up with an effective upgrade method so that upgrading to new releases is easier ... Please note that I'm not against the backporting, but do understand the arguments against it in terms of time and manpower ... I believe they are valid arguments too and if we were to do it we would definately need to be selective about which features get back ported but forward movement can be in the present tree as well. Joshua D. Drake Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 -- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC Postgresql support, programming shared hosting and dedicated hosting. +1-503-667-4564 - [EMAIL PROTECTED] - http://www.commandprompt.com PostgreSQL Replicator -- production quality replication for 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: [HACKERS] Call for 7.5 feature completion
Peter Eisentraut wrote: Joshua D. Drake wrote: Uhhh?? Are you ripping out all core pls then? plPerlNG is supposed to replace plPerl, I was talking with Bruce and he seemed to think that (as long as the code was good enough) that we could incorporate plPHP??? One reason against including plPHP in the core would be that it would create a circular build dependency between the packages postgresql and php. I think we should rather avoid that. It is no different that the dependency between plPerl and Perl, plPython and Python or worse plTCL and TCL (which typically isn't installed anymore). Sincerely, Joshua D. Drake -- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC Postgresql support, programming shared hosting and dedicated hosting. +1-503-667-4564 - [EMAIL PROTECTED] - http://www.commandprompt.com PostgreSQL Replicator -- production quality replication for PostgreSQL
Re: [HACKERS] Call for 7.5 feature completion
On Mon, 2004-05-17 at 19:39, Marc G. Fournier wrote:
On Mon, 17 May 2004, Mike Mascari wrote:
Greg Stark wrote:
Simon Riggs [EMAIL PROTECTED] writes:
I can't complete by 1 June. Think worse of me if you choose.
...
So in my perfect world I picture 7.5 freezing June 1 and releasing in July or
so, giving a nice reliable simple upgrade for people who just want a safe 7.x
series to upgrade to even after 8.0 comes out. PITR, nested transactions going
into the CVS tree sometime in June or July and being frozen as 8.0 towards the
end of the year.
A quick google of 7.4 Win32 release will reveal that the above was
precisely what was said about 7.4: it would be released to not hold
up important features like the IN optimization and a quick 7.5 would
have Win32 and PITR. It's almost as if a cron job reposts this
thread every 6 - 12 months. For those of us that are desirous of
PITR, it's a 6 month reposting that is becoming painful to read...
k, let's think this through ... 7.4 was released, what, 6 months ago? And
6 months later, PITR still isn't ready? Is there some logic here that if
7.4 wasn't released, PITR would have been done any sooner?
Potentially yes. One thing all of the developers have said they want is
more feedback from some of the more expert developers, but if we go into
feature freeze then the focus of folks like Tom and Bruce will be on
completing release, not on helping out with these new features. We had
the original patch for PITR before 7.4 went into beta IIRC, but it then
had to sit through a lengthy beta process before Tom could do some final
code review and get things committed.
Just like Bruce has often asked the community how they feel about him
balancing his time between things like speaking engagements and patch
applications, core developers have a limited amount of time they can
spend on any given development effort. If I had to pick (If I got to
pick?), I would rather see Bruce/Tom/Jan working on helping these guys
finish PITR/WIN32/Tablespaces/etc... than working on closing the 7.5
branch.
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 8: explain analyze is your friend
Re: [HACKERS] Call for 7.5 feature completion
On Tue, 18 May 2004, Robert Treat wrote: Just like Bruce has often asked the community how they feel about him balancing his time between things like speaking engagements and patch applications, core developers have a limited amount of time they can spend on any given development effort. If I had to pick (If I got to pick?), I would rather see Bruce/Tom/Jan working on helping these guys finish PITR/WIN32/Tablespaces/etc... than working on closing the 7.5 branch. Except you miss one key point here ... if Bruce/Tom/Jan have that sort of time, why aren't they doing it now? 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/faqs/FAQ.html
Re: [HACKERS] Call for 7.5 feature completion
On Sun, May 16, 2004 at 02:46:38PM -0400, Jan Wieck wrote: fact that checkpoints, vacuum runs and pg_dumps bog down their machines to the state where simple queries take several seconds care that much for any Win32 port? Do you think it is a good sign for those who have Yes. I am one such person, but from the marketing side of things, I understand perfectly well what failing to deliver on Win32 again will cost. It's not important to _me_, but that doesn't mean it's unimportant to the project. A -- Andrew Sullivan | [EMAIL PROTECTED] ---(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] Call for 7.5 feature completion
Marc G. Fournier wrote: On Tue, 18 May 2004, Robert Treat wrote: Just like Bruce has often asked the community how they feel about him balancing his time between things like speaking engagements and patch applications, core developers have a limited amount of time they can spend on any given development effort. If I had to pick (If I got to pick?), I would rather see Bruce/Tom/Jan working on helping these guys finish PITR/WIN32/Tablespaces/etc... than working on closing the 7.5 branch. Except you miss one key point here ... if Bruce/Tom/Jan have that sort of time, why aren't they doing it now? I can answer that one. We only have limited time to help a limited number of folks. I have been Win32-focussed, so haven't had time to help anyone else, and even applying patches has been delayed and folks are complaining. I have talked to Jan about helping me get PITR done. It is very close and Jan said he would work on a patch to help. I think the poster's point was that once we enter feature freeze, we have even less time to help folks, hence no progress in PITR until long after 7.4. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (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] Call for 7.5 feature completion
On Tue, 2004-05-18 at 09:30, Andrew Sullivan wrote: On Sun, May 16, 2004 at 02:46:38PM -0400, Jan Wieck wrote: fact that checkpoints, vacuum runs and pg_dumps bog down their machines to the state where simple queries take several seconds care that much for any Win32 port? Do you think it is a good sign for those who have Yes. I am one such person, but from the marketing side of things, I understand perfectly well what failing to deliver on Win32 again will cost. It's not important to _me_, but that doesn't mean it's unimportant to the project. My primary fear about delivering Win32 with all of these other great features is that, IMO, there is a higher level of risk associated with these advanced features. At the same time, this will be the first trial for many Win32 users. Should there be some problems, in general, or worse, specific to Win32 users as it relates to these new features, it could cost some serious Win32/PostgreSQL community points. A troubled release which is experienced by Win32 users is going to be a battle cry for MySQL. I've been quietly hoping that these great new features would become available a release before Win32 was completed. That way, a shake down would occur before the Win32 audience got a hold of it. Which, in turn, should make for a great Win32 experience. I guess my point is, if these other features don't make it into 7.5 and Win32 does, that might still be a good thing for the potential Win32 market. Granted, if I was a developer on one of these big features and it didn't make it, I too would be fairly disappointed. Yet, once we get a release out with Win32, it should help give everyone a feel for the ability to actually support this new audience and platform. If there is a large influx of users compounded by problems, I suspect it's again, going to reflect poorly on the PostgreSQL community. ...just some ramblings -- Greg Copeland, Owner [EMAIL PROTECTED] Copeland Computer Consulting 940.206.8004 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Call for 7.5 feature completion
Marc G. Fournier wrote: On Tue, 18 May 2004, Robert Treat wrote: Just like Bruce has often asked the community how they feel about him balancing his time between things like speaking engagements and patch applications, core developers have a limited amount of time they can spend on any given development effort. If I had to pick (If I got to pick?), I would rather see Bruce/Tom/Jan working on helping these guys finish PITR/WIN32/Tablespaces/etc... than working on closing the 7.5 branch. Except you miss one key point here ... if Bruce/Tom/Jan have that sort of time, why aren't they doing it now? Well I think you might of missed his point. His point was if he could pick their priorities. I would kind of agree with Robert except that there are other dynamics involved... Jan works for Afilias thus does what Afilias directs him to do and what that is right now is Slony-I. Tom works for RedHat but from what I can tell is basically a rogue agent ;). However if Tom stops works what he is doing to help with PITR etc... I think a lot of the innner world of PostgreSQL would simply stop (if I am wrong please correct me). Bruce --- well what can you say about Bruce ;). Seriously though, we all have the roles that we play. I don't think redirecting specific resources to other resources will help beyond slowing up the original resources. Sincerely, Joshua D. Drake 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/faqs/FAQ.html -- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC Postgresql support, programming shared hosting and dedicated hosting. +1-503-667-4564 - [EMAIL PROTECTED] - http://www.commandprompt.com PostgreSQL Replicator -- production quality replication for PostgreSQL
Re: [HACKERS] Call for 7.5 feature completion
Joshua D. Drake wrote: Except you miss one key point here ... if Bruce/Tom/Jan have that sort of time, why aren't they doing it now? Well I think you might of missed his point. His point was if he could pick their priorities. I would kind of agree with Robert except that there are other dynamics involved... Jan works for Afilias thus does what Afilias directs him to do and what that is right now is Slony-I. Tom works for RedHat but from what I can tell is basically a rogue agent I like the rogue agent. I want to be one too. :-) ;). However if Tom stops works what he is doing to help with PITR etc... I think a lot of the innner world of PostgreSQL would simply stop (if I am wrong please correct me). Bruce --- well what can you say about Bruce ;). Seriously though, we all have the roles that we play. I don't think redirecting specific resources to other resources will help beyond slowing up the original resources. Tom is actually working on doing the fsync change for Win32 and to remove the unix dependency on sync, so in a way he is on the Win32 train right now. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (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: [HACKERS] Call for 7.5 feature completion
Joshua D. Drake wrote: One reason against including plPHP in the core would be that it would create a circular build dependency between the packages postgresql and php. I think we should rather avoid that. It is no different that the dependency between plPerl and Perl, plPython and Python or worse plTCL and TCL (which typically isn't installed anymore). This is very much different, because the PHP distribution contains the PostgreSQL driver, whereas the other languages do not. So you would have PHP build depends on PostgreSQL PostgreSQL build depends on PHP Not good. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Call for 7.5 feature completion
Marko Karppinen wrote: I guess the key thing is that pgFoundry shouldn't be a community distinct from the core. The same community standards need to apply on both sides of the fence. Yes, and the best way to achieve that would be to not have anything to pgfoundry and keep everything in the core. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Call for 7.5 feature completion
This is very much different, because the PHP distribution contains the PostgreSQL driver, whereas the other languages do not. So you would have PHP build depends on PostgreSQL Ahh I see your point, EXCEPT :) plPHP does not require PostgreSQL support to be built into PHP. Sincerely, Joshua D. Drake PostgreSQL build depends on PHP Not good. -- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC Postgresql support, programming shared hosting and dedicated hosting. +1-503-667-4564 - [EMAIL PROTECTED] - http://www.commandprompt.com Mammoth PostgreSQL Replicator. Integrated Replication for PostgreSQL begin:vcard fn:Joshua D. Drake n:Drake;Joshua D. org:Command Prompt, Inc. adr:;;PO Box 215;Cascade Locks;Oregon;97014;USA email;internet:[EMAIL PROTECTED] title:Consultant tel;work:503-667-4564 tel;fax:503-210-0034 note:Command Prompt, Inc. is the largest and oldest US based commercial PostgreSQL support provider. We provide the only commercially viable integrated PostgreSQL replication solution, but also custom programming, and support. We authored the book Practical PostgreSQL, the procedural language plPHP, and adding trigger capability to plPerl. x-mozilla-html:FALSE url:http://www.commandprompt.com/ version:2.1 end:vcard ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Call for 7.5 feature completion
That is irrelevant. A normal binary package of PHP does build the PostgreSQL support (which is surely in our interest), so the build dependency holds. Then I am afraid I don't understand the actual problem. plPHP does not create a circular dependency because it doesn't require PHP to have PostgreSQL support. Also PHP does not compile the PostgreSQL support by default. This is no different that Perl, which also has a PostgreSQL driver but plPerl does not require DBD::Pg to compile. Sincerely, Joshua D. Drake Sincerely, Joshua D. Drake PostgreSQL build depends on PHP Not good. -- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC Postgresql support, programming shared hosting and dedicated hosting. +1-503-667-4564 - [EMAIL PROTECTED] - http://www.commandprompt.com Mammoth PostgreSQL Replicator. Integrated Replication for PostgreSQL begin:vcard fn:Joshua D. Drake n:Drake;Joshua D. org:Command Prompt, Inc. adr:;;PO Box 215;Cascade Locks;Oregon;97014;USA email;internet:[EMAIL PROTECTED] title:Consultant tel;work:503-667-4564 tel;fax:503-210-0034 note:Command Prompt, Inc. is the largest and oldest US based commercial PostgreSQL support provider. We provide the only commercially viable integrated PostgreSQL replication solution, but also custom programming, and support. We authored the book Practical PostgreSQL, the procedural language plPHP, and adding trigger capability to plPerl. x-mozilla-html:FALSE url:http://www.commandprompt.com/ version:2.1 end:vcard ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Call for 7.5 feature completion
Joshua D. Drake wrote: This is very much different, because the PHP distribution contains the PostgreSQL driver, whereas the other languages do not. So you would have PHP build depends on PostgreSQL Ahh I see your point, EXCEPT :) plPHP does not require PostgreSQL support to be built into PHP. That is irrelevant. A normal binary package of PHP does build the PostgreSQL support (which is surely in our interest), so the build dependency holds. Sincerely, Joshua D. Drake PostgreSQL build depends on PHP Not good. ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Call for 7.5 feature completion
Joshua D. Drake wrote: Also PHP does not compile the PostgreSQL support by default. But most binary packages do, and they are the ones I'm talking about. And surely you do not advocate that, in order to build PL/PHP, the packagers instead disable the client side support in PHP? ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Call for 7.5 feature completion
Joshua D. Drake wrote: Of course not, but I still don't see your point. plPHP doesn't need PHP+PostgreSQL support. Nor does PHP+PostgreSQL conflict with using plPHP... PHP doesn't even need to be installed for plPHP to work... You just need the source tree for building. I don't talk about manual build processes, I talk about (semi-)automatic package builds. The PHP package has a build dependency on PostgreSQL, because it needs libpq. So PostgreSQL needs to be built and installed before PHP can be built. But then, if PL/PHP were to be integrated into PostgreSQL, PHP needs to be installed first, so the PostgreSQL+PL/PHP build can get at the PHP headers files and whatever else it needs. So you can neither build PHP first nor build PostgreSQL first. So building PL/PHP doesn't need a PHP with PostgreSQL support. But no one is going to build two versions of PHP packages just so PostgreSQL can build. That is a mess we can happily avoid. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Call for 7.5 feature completion
Peter Eisentraut wrote: Joshua D. Drake wrote: Of course not, but I still don't see your point. plPHP doesn't need PHP+PostgreSQL support. Nor does PHP+PostgreSQL conflict with using plPHP... PHP doesn't even need to be installed for plPHP to work... You just need the source tree for building. O.k. now I get it.. Basically you are saying that in order to build plPHP you need PHP and PostgreSQL (regardless if they know about each other). So in order to build plPHP you need to build PostgreSQL, then PHP, then plPHP... versus just Postgresql+plPHP... However plPHP is a configure option (when patched)... Thus if they choose with-php then they would (presumably) know what they were getting into. That makes sense. Sincerely, Joshua D. Drake I don't talk about manual build processes, I talk about (semi-)automatic package builds. The PHP package has a build dependency on PostgreSQL, because it needs libpq. So PostgreSQL needs to be built and installed before PHP can be built. But then, if PL/PHP were to be integrated into PostgreSQL, PHP needs to be installed first, so the PostgreSQL+PL/PHP build can get at the PHP headers files and whatever else it needs. So you can neither build PHP first nor build PostgreSQL first. So building PL/PHP doesn't need a PHP with PostgreSQL support. But no one is going to build two versions of PHP packages just so PostgreSQL can build. That is a mess we can happily avoid. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Call for 7.5 feature completion
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 What can be done? Well, money from Fujitsu and other companies (Afilias/Sloney, Command Prompt/ecpg-plPHP), is allowing us to hit some of these bigger items, so hopefully that will move us forward in these complex areas. I am not sure what could have been done to push some of these projects along faster. Perhaps some more public cajoling of the masses into helping out would be good. Not just development but testing. Occasional posts on general asking people to help test Win32 and PITR for example, or a prominent link on the main page asking people to try out the latest Win32. It may not be beta-ready yet, but it surely could not hurt to have people start testing as soon as possible. I'm also sure that there is probably some more development talent available out there that could help in some of these bigger items, but I've not seen a lot of people asking for help or suggesting ways that people could help. I realize that some of this items are large and complex, but there is always /something/ that people can do, even if it documentating new features, or even documenting how to understand the new feature from a developer's perspective. - -- Greg Sabino Mullane [EMAIL PROTECTED] PGP Key: 0x14964AC8 200405182046 -BEGIN PGP SIGNATURE- iD8DBQFAqq6GvJuQZxSWSsgRAuruAKCkzWbtYcfu9DR+f4JUHKPWjaPiswCg/Vcf ZGLywaE2OOgr3Mk+Kua1fUA= =vqHP -END PGP SIGNATURE- ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Call for 7.5 feature completion
Seriously though, we all have the roles that we play. I don't think redirecting specific resources to other resources will help beyond slowing up the original resources. And now Neil's on holidays :) Perhaps we need more committers. The deluge of patches is starting to strain the major developers I think? Chris ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Call for 7.5 feature completion
Greg Copeland writes: My primary fear about delivering Win32 with all of these other great features is that, IMO, there is a higher level of risk associated with these advanced features. At the same time, this will be the first trial for many Win32 users. Should there be some problems, in general, or worse, specific to Win32 users as it relates to these new features, it could cost some serious Win32/PostgreSQL community points. A troubled release which is experienced by Win32 users is going to be a battle cry for MySQL. Just thought I'd jump in here with my $0.02. It was always my expectation that the first Win32 release, regardless of the features which accompanied it, would be clearly advertised as not for production (some here might suggest that simply mentioning Win32 and not for production in the same sentence is repeating myself, but I'm not going to be quite so cynical). It won't stop people going ahead and doing it regardless, but it buys us some press insurance. I'm confident that the Win32 port will be solid, and will go a long way in boosting PostgreSQLs popularity. That said, I simply don't think it isn't reasonable to expect that it'll go out the door with all quirks nailed the very first time, and we ought to be honest and up-front about these expectations. Cheers, Claudio --- Certain disclaimers and policies apply to all email sent from Memetrics. For the full text of these disclaimers and policies see a href=http://www.memetrics.com/emailpolicy.html;http://www.memetrics.com/em ailpolicy.html/a ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Call for 7.5 feature completion
On Tuesday 18 May 2004 17:33, Joshua D. Drake wrote: But most binary packages do, and they are the ones I'm talking about. And surely you do not advocate that, in order to build PL/PHP, the packagers instead disable the client side support in PHP? Of course not, but I still don't see your point. plPHP doesn't need PHP+PostgreSQL support. Nor does PHP+PostgreSQL conflict with using plPHP... PHP doesn't even need to be installed for plPHP to work... You just need the source tree for building. So you then have to build PHP twice, in an RPM build environment. You mean I can't just have the headers installed to build plPHP? So, follow the sequence of the RPM building events: 1.) Build PHP without PostgreSQL client support. 2.) Build PostgreSQL 3.) Build plPHP 4.) Build PHP with PostgreSQL client support. The Perl situation is totally different, since the Perl client is not part of the Perl source tree. The 4-step I mention above would never be followed by any distributions, who would probably just not build plPHP to keep from having the circular dependency. See, in the RPM build environment for self-hosting distributions, I would have to pull in the entire PHP source distribution during the PostgreSQL build. Keeping that synchronized with the PHP version that is the main one distributed would be a major pain. Better would be getting plPHP so that it doesn't need the PostgreSQL source tree, but just needs the development headers (with server-side) installed. Then there is no circular build dependency. Then I just: 1.) Build PostgreSQL 2.) Build PHP (with PostgreSQL client support) 3.) Build plPHP (with PostgreSQL SPI support, or maybe even PostgreSQL client support for cross database queries? :-)) Try building the RPMs for PHP plus PostgreSQL and plPHP, then tell me how you solved the circular dependency. -- Lamar Owen Director of Information Technology Pisgah Astronomical Research Institute 1 PARI Drive Rosman, NC 28772 (828)862-5554 www.pari.edu ---(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] Call for 7.5 feature completion
So you then have to build PHP twice, in an RPM build environment. You mean I can't just have the headers installed to build plPHP? So, follow the No you need to make sure that PHP is available as a shared lib. 1.) Build PostgreSQL 2.) Build PHP (with PostgreSQL client support) 3.) Build plPHP (with PostgreSQL SPI support, or maybe even PostgreSQL client support for cross database queries? :-)) Right. Try building the RPMs for PHP plus PostgreSQL and plPHP, then tell me how you solved the circular dependency. Actually plPHP doesn't require the PostgreSQL source tree... you would just have to modify the Make file to point to the right places. J ---(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] Call for 7.5 feature completion
On Tuesday 18 May 2004 21:58, Joshua D. Drake wrote: So you then have to build PHP twice, in an RPM build environment. You mean I can't just have the headers installed to build plPHP? So, follow the No you need to make sure that PHP is available as a shared lib. Which requires you to build PHP. PHP is only going to get built once; do you build with or without PostgreSQL client support? As an RPM builder, you cannot build it one way, then rebuild it again another way. It's not self-hosting at that point. Try building the RPMs for PHP plus PostgreSQL and plPHP, then tell me how you solved the circular dependency. Actually plPHP doesn't require the PostgreSQL source tree... you would just have to modify the Make file to point to the right places. Then it can easily be a standalone project, and the issues go away. -- Lamar Owen Director of Information Technology Pisgah Astronomical Research Institute 1 PARI Drive Rosman, NC 28772 (828)862-5554 www.pari.edu ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Call for 7.5 feature completion
On Tue, 18 May 2004, Heikki Linnakangas wrote: I'd like to get the patch committed as soon as the 7.6 release cycle begins, with whatever limitations it has at that time. The nice thing of this is that then you have a development cycle for others to help ... your patch lays down the this is the direction, now add to it ... I'd love to see 7.6 start off with a bunch of very large patches that can be then fleshed out over the course of the development cycle ... instead of a bunch of patches at the end of teh development cycle cause everyone is trying to squeeze things in ... 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: [HACKERS] Call for 7.5 feature completion
On Tue, 18 May 2004, Joshua D. Drake wrote: Actually plPHP doesn't require the PostgreSQL source tree... you would just have to modify the Make file to point to the right places. So, why tie it into the PostgreSQL source tree? Won't it be popular enough to live on its own, that it has to be distributed as part of the core? 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/faqs/FAQ.html
Re: [HACKERS] Call for 7.5 feature completion
On Mon, 17 May 2004, Alvaro Herrera Munoz wrote: I have some confidence in that I will be able to deliver it maybe the last week of May. I can only hope, however, that it will not be rejected because it's presented too close to feature freeze. There is no such thing as too close to feature freeze, nor has there ever been in the past ... other then missing it altogether. Unless there are some serious flaws in the implementation, submitting it on May 31st would get it in ...it isn't expecting to be rock solid, bug free, that is what the beta period is to work out ... What is expected, though, is that you won't disappear after its committed, so that you can fix any bugs reported in a timely manner ... 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] Call for 7.5 feature completion
On Tue, 18 May 2004, Joshua D. Drake wrote: Actually plPHP doesn't require the PostgreSQL source tree... you would just have to modify the Make file to point to the right places. So, why tie it into the PostgreSQL source tree? Won't it be popular enough to live on its own, that it has to be distributed as part of the core? At least in Japan PHP is much more popular than Python. If we have plpython in core, I see no reason we do not have plPHP in core at least from the popularity point of view. -- Tatsuo Ishii ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Call for 7.5 feature completion
Marc G. Fournier wrote: On Mon, 17 May 2004, Alvaro Herrera Munoz wrote: I have some confidence in that I will be able to deliver it maybe the last week of May. I can only hope, however, that it will not be rejected because it's presented too close to feature freeze. There is no such thing as too close to feature freeze, nor has there ever been in the past ... other then missing it altogether. Unless there are some serious flaws in the implementation, submitting it on May 31st would get it in ...it isn't expecting to be rock solid, bug free, that is what the beta period is to work out ... What is expected, though, is that you won't disappear after its committed, so that you can fix any bugs reported in a timely manner ... Not completely true. If a patch needs major rework or the implemention isn't acceptable, it might be rejected and have to wait --- it has happened before, and PITR might not make it because the April 1 patch wasn't an acceptable implementation. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (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] Call for 7.5 feature completion
So, why tie it into the PostgreSQL source tree? Won't it be popular enough to live on its own, that it has to be distributed as part of the core? Honestly, I don't know if it would be popular enough on its own. Now the plPerlNG that Andrew and us are working, yes but plPHP? It is nifty, it is cool, it is very capable but it is still PHP. I think the point of having it in core is that the three most popular user space languages are: Python Perl PHP If those are covered within core under the pl* then we have all bases covered. I am not saying that it should be in core (although I definately think plPerlNG should be). This all started because it was suggested it could be :) J Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 -- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC Postgresql support, programming shared hosting and dedicated hosting. +1-503-667-4564 - [EMAIL PROTECTED] - http://www.commandprompt.com PostgreSQL Replicator -- production quality replication for PostgreSQL ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Call for 7.5 feature completion
Tatsuo Ishii wrote: At least in Japan PHP is much more popular than Python. If we have plpython in core, I see no reason we do not have plPHP in core at least from the "popularity" point of view. Well I don't know anywhere that PHP isn't more popular than Python. The question I think is a technical one. Python is a better "language" that PHP is. Perl is as well but that is a whole other argument. PHP is what I call the "Dumb Monkey" language. It isn't meant to be rude, but the reality is that almost any dumb monkey can code something in PHP. Python takes actual thought to produce something useful. Whether or not that is a bad thing is for another argument :) Sincerely, Joshua D. Drake -- Tatsuo Ishii ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org -- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC Postgresql support, programming shared hosting and dedicated hosting. +1-503-667-4564 - [EMAIL PROTECTED] - http://www.commandprompt.com PostgreSQL Replicator -- production quality replication for PostgreSQL
Re: [HACKERS] Call for 7.5 feature completion
Marc G. Fournier wrote: On Mon, 17 May 2004, Bruce Momjian wrote: Marc G. Fournier wrote: Agreed, but you are a me too, not a huge percentage of our userbase. How do you know? Have you polled our complete userbase? Basically, after 6-7 months of development, I want more than a vacuum patch and a new cache replacement policy. I want something big, in fact, several big things. Most likely won't happen, since what is considered big by you isn't necessarily what is considered big by someone else ... as Hannu, and I believe, Jan, have so far pointed out to you ... I can't poll for everything. I make my own educated guesses. Based on what though? All the clients that I deal with on a daily basis generally care about is performance ... that is generally what they upgrade for ... so, my 'educated guess' based on real world users is that Win32, PITR and nested transactions are not important ... tablespaces, I have one client that has asked about something *similar* to it, but tablespaces, for him, doesn't come close to what they would like to see ... So, my 'educated guess' is different then yours is ... does that make yours wrong? Nope ... just means we have different sample sets to work with ... Interesting. We have made COMPLETELY different experiences. There is one question people ask me daily: When can we have sychronous replication and PITR?. Performance is not a problem here. People are more interested in stability and enterprise features such as those I have mentioned above. I am still wondering about two things: Somebody has posted a 2PC patch - I haven't seen too many comments Somebody has posted sync multimaster replication (PgCluster) - nobody has commented on that. Maybe I am the only one who has ever tried it ... Most likely this is not very encourageing for the developers involved ... Regards, Hans -- Cybertec Geschwinde u Schoenig Schoengrabern 134, A-2020 Hollabrunn, Austria Tel: +43/720/10 1234567 or +43/664/233 90 75 www.cybertec.at, www.postgresql.at, kernel.cybertec.at ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Call for 7.5 feature completion
Hans-Jürgen Schönig wrote: All the clients that I deal with on a daily basis generally care about is performance ... that is generally what they upgrade for ... so, my 'educated guess' based on real world users is that Win32, PITR and nested transactions are not important ... tablespaces, I have one client that has asked about something *similar* to it, but tablespaces, for him, doesn't come close to what they would like to see ... So, my 'educated guess' is different then yours is ... does that make yours wrong? Nope ... just means we have different sample sets to work with ... Interesting. We have made COMPLETELY different experiences. There is one question people ask me daily: When can we have sychronous replication and PITR?. Performance is not a problem here. People are more interested in stability and enterprise features such as those I have mentioned above. I am still wondering about two things: Somebody has posted a 2PC patch - I haven't seen too many comments He is waiting for nested transactions to be committed so he can merge his work in. Somebody has posted sync multimaster replication (PgCluster) - nobody has commented on that. Maybe I am the only one who has ever tried it ... I think it should be on gborg. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (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] Call for 7.5 feature completion
Marc G. Fournier wrote: On Sun, 16 May 2004, Bruce Momjian wrote: I personally don't think Win32 is enough of a new feature either, but others disagree. Jan, correct me if I'm wrong ... Jan's point is that we have enough already to warrant a beta on June 1st, even without Win32 ... Win32 (or any of the other stuff, like PITR/tablespaces) would be icing on the cake ... I agree that we don't have many of the big marketing bang for the buck features done for 7.5. But that is no reason to use wordings like nifty enhancements or for a small percentage in an attempt to make what we have look uninteresting for the average user so that it looks wise to wait, and wait, and wait. Just that someone doesn't understand the importance of these issues because he doesn't deal with the type of customer that values a good standard deviation on response times doesn't make Win32 more important. Judging by those standards, we probably shouldn't have had 7.4 at all, and we probably shouldn't claim that we want to attract typical Oracle users either. Jan -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # ---(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] Call for 7.5 feature completion
Jan Wieck wrote: Christopher Kings-Lynne wrote: Jan, correct me if I'm wrong ... Jan's point is that we have enough already to warrant a beta on June 1st, even without Win32 ... Win32 (or any of the other stuff, like PITR/tablespaces) would be icing on the cake ... I think we're close enough on win32 to wait for it. It would look bad for us to miss inclusion of win32 two releases in a row... Yes, unless this is forever. Is there a clear commitment that Win32 will be done if we push from June to July? It is too late to think about pushing back another month. We had this discussion already. June 1 is it. I do think Win32 will make it, though. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (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: [HACKERS] Call for 7.5 feature completion
It is too late to think about pushing back another month. We had this discussion already. June 1 is it. I thought the outcome of that discussion was June 15 ? Can we try to do the 2PC patch now instead of waiting for subtransactions ? Andreas ---(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] Call for 7.5 feature completion
Robert Treat wrote: On Monday 17 May 2004 08:21, Bruce Momjian wrote: Hans-J?rgen Sch?nig wrote: I am still wondering about two things: Somebody has posted a 2PC patch - I haven't seen too many comments He is waiting for nested transactions to be committed so he can merge his work in. I was thinking about this over the weekend... if nested transactions doesn't make it into 7.5, does this mean that we won't get 2PC either? Seems that would be a shame if we have a 2PC patch that is ready to go... No idea. The 2PC author wanted to wait for subtransactions. It wasn't our idea. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (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: [HACKERS] Call for 7.5 feature completion
On Monday 17 May 2004 08:21, Bruce Momjian wrote:
Hans-Jürgen Schönig wrote:
I am still wondering about two things:
Somebody has posted a 2PC patch - I haven't seen too many comments
He is waiting for nested transactions to be committed so he can merge
his work in.
I was thinking about this over the weekend... if nested transactions doesn't
make it into 7.5, does this mean that we won't get 2PC either? Seems that
would be a shame if we have a 2PC patch that is ready to go...
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 8: explain analyze is your friend
Re: [HACKERS] Call for 7.5 feature completion
Jan Wieck wrote: I am still wondering about two things: Somebody has posted a 2PC patch - I haven't seen too many comments Somebody has posted sync multimaster replication (PgCluster) - nobody has commented on that. Maybe I am the only one who has ever tried it ... Do you really need someone commenting on query based replication? I get goosebumps from just thinking someone would voluntarily push all sequence- or timestamp-generation and other not strictly deterministic functionality into the application to be able to use such a solution. This is exactly how people work around all the MySQL idiosyncrasies. Most likely this is not very encourageing for the developers involved ... Most hopefully this is very discouraging! Connection pools are a nice thing and I have used pgpool recently with great success, for pooling connections. But attempting to deliver multimaster replication as a byproduct of a connection pool isn't going to become an enterprise feature. And the more half-baked, half-functional and half-reliable replication attempts there are, the harder it will be to finally get a real solution being recognized. Well, considering we offer _nothing_ for multi-master right now, I think it is a valuable project. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (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] Call for 7.5 feature completion
Hans-Jürgen Schönig wrote: Marc G. Fournier wrote: On Mon, 17 May 2004, Bruce Momjian wrote: Marc G. Fournier wrote: Agreed, but you are a me too, not a huge percentage of our userbase. How do you know? Have you polled our complete userbase? Basically, after 6-7 months of development, I want more than a vacuum patch and a new cache replacement policy. I want something big, in fact, several big things. Most likely won't happen, since what is considered big by you isn't necessarily what is considered big by someone else ... as Hannu, and I believe, Jan, have so far pointed out to you ... I can't poll for everything. I make my own educated guesses. Based on what though? All the clients that I deal with on a daily basis generally care about is performance ... that is generally what they upgrade for ... so, my 'educated guess' based on real world users is that Win32, PITR and nested transactions are not important ... tablespaces, I have one client that has asked about something *similar* to it, but tablespaces, for him, doesn't come close to what they would like to see ... So, my 'educated guess' is different then yours is ... does that make yours wrong? Nope ... just means we have different sample sets to work with ... Interesting. We have made COMPLETELY different experiences. There is one question people ask me daily: When can we have sychronous replication and PITR?. Performance is not a problem here. People are more interested in stability and enterprise features such as those I have mentioned above. I am still wondering about two things: Somebody has posted a 2PC patch - I haven't seen too many comments Somebody has posted sync multimaster replication (PgCluster) - nobody has commented on that. Maybe I am the only one who has ever tried it ... Do you really need someone commenting on query based replication? I get goosebumps from just thinking someone would voluntarily push all sequence- or timestamp-generation and other not strictly deterministic functionality into the application to be able to use such a solution. This is exactly how people work around all the MySQL idiosyncrasies. Most likely this is not very encourageing for the developers involved ... Most hopefully this is very discouraging! Connection pools are a nice thing and I have used pgpool recently with great success, for pooling connections. But attempting to deliver multimaster replication as a byproduct of a connection pool isn't going to become an enterprise feature. And the more half-baked, half-functional and half-reliable replication attempts there are, the harder it will be to finally get a real solution being recognized. Jan -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Call for 7.5 feature completion
Jan Wieck wrote: Marc G. Fournier wrote: On Sun, 16 May 2004, Bruce Momjian wrote: I personally don't think Win32 is enough of a new feature either, but others disagree. Jan, correct me if I'm wrong ... Jan's point is that we have enough already to warrant a beta on June 1st, even without Win32 ... Win32 (or any of the other stuff, like PITR/tablespaces) would be icing on the cake ... I agree that we don't have many of the big marketing bang for the buck features done for 7.5. But that is no reason to use wordings like nifty That was my only point, that we don't have any big marketing bang for the buck features. I don't mean to minimize the good work we have already done. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (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: [HACKERS] Call for 7.5 feature completion
Marc G. Fournier wrote: On Mon, 17 May 2004, Bruce Momjian wrote: Most hopefully this is very discouraging! Connection pools are a nice thing and I have used pgpool recently with great success, for pooling connections. But attempting to deliver multimaster replication as a byproduct of a connection pool isn't going to become an enterprise feature. And the more half-baked, half-functional and half-reliable replication attempts there are, the harder it will be to finally get a real solution being recognized. Well, considering we offer _nothing_ for multi-master right now, I think it is a valuable project. Connection pooling is *not* multi master ... it doesn't even simulate multi-master ... multi-master, at least as far as I'm aware, means no point of failure, and connection pooling creates a *single* point of failure ... the pgpool process dies, you've lost all connections to the database ... I think people are confusing pgpool with pgcluster. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (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] Call for 7.5 feature completion
On Mon, 17 May 2004, Bruce Momjian wrote: Most hopefully this is very discouraging! Connection pools are a nice thing and I have used pgpool recently with great success, for pooling connections. But attempting to deliver multimaster replication as a byproduct of a connection pool isn't going to become an enterprise feature. And the more half-baked, half-functional and half-reliable replication attempts there are, the harder it will be to finally get a real solution being recognized. Well, considering we offer _nothing_ for multi-master right now, I think it is a valuable project. Connection pooling is *not* multi master ... it doesn't even simulate multi-master ... multi-master, at least as far as I'm aware, means no point of failure, and connection pooling creates a *single* point of failure ... the pgpool process dies, you've lost all connections to the database ... 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: [HACKERS] Call for 7.5 feature completion
Interesting. We have made COMPLETELY different experiences. There is one question people ask me daily: When can we have sychronous replication and PITR?. Performance is not a problem here. People are more interested in stability and enterprise features such as those I have mentioned above. I doubt that. Having deployed several 7.4 databases, the first customers ask (of course not in technical speech, but in the meaning) when the problem with checkpoint hogging system down is solved. This is a really serious issue, especially when using drbd + ext3. The system will become really unresponsive when checkpoint is running. I heavily await 7.5 because of the background writer. ---(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] Call for 7.5 feature completion
Mario Weilguni wrote: Interesting. We have made COMPLETELY different experiences. There is one question people ask me daily: When can we have sychronous replication and PITR?. Performance is not a problem here. People are more interested in stability and enterprise features such as those I have mentioned above. I doubt that. Having deployed several 7.4 databases, the first customers ask (of course not in technical speech, but in the meaning) when the problem with checkpoint hogging system down is solved. This is a really serious issue, especially when using drbd + ext3. The system will become really unresponsive when checkpoint is running. I heavily await 7.5 because of the background writer. This thread reminds me of Andrew Sullivan's signature: The plural of anecdote is not data - Roger Brinner Of course, once the sample size becomes sufficiently large, it does become data. Has the advocacy group performed any polling in this area that might shed some light as to what users and potential users might want? Mike Mascari ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Call for 7.5 feature completion
On Mon, 2004-05-17 at 15:10, Bruce Momjian wrote: It is too late to think about pushing back another month. We had this discussion already. June 1 is it. I think I have to reiterate: PITR won't make 1 June. (I will be away travelling soon). This has been said a number of times. This is all rather disheartening, having laid out a time plan months back, noting some of this. Yes, I am working on it, and no, I'm not hand waving, but I do take time off every million keystrokes or so. Mid to late June is a realistic time for the completion of PITR, given the additional features I am now working on and the time allocation I can reasonably give this (which in many ways is already unreasonable). My last publicly stated completion estimate was right to within a few days (mid-April, stated in early March). I'm a very task focused person and I strongly support the notion of deadlines and freezes. It's just in this instance, 1 June seems to have been plucked from the air - unless there are other pressures that others can see better than I. What are they again? 7.5dev is loads better than 7.4, though that was true in February. Having waited until now, why not wait for the features? If somebody suggested that we do 7.5 now and then 8.0 with Win32 PITR in September, I'd think about that, but I'm worried that the next major release is a long way out after this next one, not a few months. Beta is gonna take ages anyhow. Many people in the community are still using 7.3 or below. If the releases come too frequently, running an initdb is just a pain, especially with out a big reason to sell to the business folks as to why they have to put up with the downtime of upgrading (or time spent on clever plans). Is it running? Yeh. So why upgrade? for existing users, and Does it have feature XYZ? No, but they think next release. OK, well, we'll wait for that and then trial it for new adopters. Shipping too early is a bad thing too. It's not clear to me why you would ship in a hurry when the community has waited years to get some of the features on the URGENT list. Honestly, how long has PITR been brewing? And, who thinks that we'll get increased adoption without the big ticket items? (Even if your opinion is that PITR isn't one of them). I can't complete by 1 June. Think worse of me if you choose. Best Regards, Simon Riggs ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Call for 7.5 feature completion
Hans-Jürgen Schönig wrote: Somebody has posted sync multimaster replication (PgCluster) - nobody has commented on that. Maybe I am the only one who has ever tried it ... I didn't find it on pgFoundry, others place to look at it ? Regards Gaetano Mendola ---(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] Call for 7.5 feature completion
Bruce Momjian wrote: Marc G. Fournier wrote: On Mon, 17 May 2004, Bruce Momjian wrote: Most hopefully this is very discouraging! Connection pools are a nice thing and I have used pgpool recently with great success, for pooling connections. But attempting to deliver multimaster replication as a byproduct of a connection pool isn't going to become an enterprise feature. And the more half-baked, half-functional and half-reliable replication attempts there are, the harder it will be to finally get a real solution being recognized. Well, considering we offer _nothing_ for multi-master right now, I think it is a valuable project. Connection pooling is *not* multi master ... it doesn't even simulate multi-master ... multi-master, at least as far as I'm aware, means no point of failure, and connection pooling creates a *single* point of failure ... the pgpool process dies, you've lost all connections to the database ... I think people are confusing pgpool with pgcluster. And you wonder where that's coming from, eh? Tatsuo is advertising pgpool as a synchronous replication system suitable for failover. Quoting from the pgpool-1.0 README: pgpool could be used as a replication server. This allows real-time backuping of the database to avoid disk failures. pgpool sends exactly same query to each PostgreSQL servers to accomplish replication. So pgpool can be regarded as a synchronous replication server. Don't get me wrong, as said pgpool works great for the purpose I tested, the pooling. But statements like that are causing the confusion here. Jan -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Call for 7.5 feature completion
Simon Riggs wrote: On Mon, 2004-05-17 at 15:10, Bruce Momjian wrote: It is too late to think about pushing back another month. We had this discussion already. June 1 is it. Just to throw in my .02, plPerlNG won't be ready for testing until mid, later June either. Then there is also plPHP which although we haven't had any bug reports still needs some more peer review. Also we would like to submit our ECPG which includes SET DESCRIPTOR and error handling but that too needs more peer review. It just seems, considering the current state of 7.4.2 (stable, just now being deployed in production shops) that we should make a longer development time for 7.5. Personally, Win32, subtransactions and PITR are what we are after. Second would be inclusion of plPHP and plPerlNG which are arguably the most widely used languages to connect to PostgreSQL. Sincerely, Joshua D. Drake -- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC Postgresql support, programming shared hosting and dedicated hosting. +1-503-667-4564 - [EMAIL PROTECTED] - http://www.commandprompt.com Mammoth PostgreSQL Replicator. Integrated Replication for PostgreSQL begin:vcard fn:Joshua D. Drake n:Drake;Joshua D. org:Command Prompt, Inc. adr:;;PO Box 215;Cascade Locks;Oregon;97014;USA email;internet:[EMAIL PROTECTED] title:Consultant tel;work:503-667-4564 tel;fax:503-210-0034 note:Command Prompt, Inc. is the largest and oldest US based commercial PostgreSQL support provider. We provide the only commercially viable integrated PostgreSQL replication solution, but also custom programming, and support. We authored the book Practical PostgreSQL, the procedural language plPHP, and adding trigger capability to plPerl. x-mozilla-html:FALSE url:http://www.commandprompt.com/ version:2.1 end:vcard ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Call for 7.5 feature completion
On Mon, 17 May 2004, Joshua D. Drake wrote: Personally, Win32, subtransactions and PITR are what we are after. Second would be inclusion of plPHP and plPerlNG which are arguably the most widely used languages to connect to PostgreSQL. plPHP and plPerlNG both belong on pgfoundry, not in the core distribution ... 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] Call for 7.5 feature completion
Mario Weilguni wrote: Interesting. We have made COMPLETELY different experiences. There is one question people ask me daily: When can we have sychronous replication and PITR?. Performance is not a problem here. People are more interested in stability and enterprise features such as those I have mentioned above. I doubt that. Having deployed several 7.4 databases, the first customers ask (of course not in technical speech, but in the meaning) when the problem with checkpoint hogging system down is solved. This is a really serious issue, especially when using drbd + ext3. ^^^ Well that seems to be part of the problem. ext3 does not scale well at all under load. You should probably upgrade to a better FS (like XFS). I am not saying that your point isn't valid (it is) but upgrading to a better FS will help you. Sincerely, Joshua D. Drake The system will become really unresponsive when checkpoint is running. I heavily await 7.5 because of the background writer. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED]) -- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC Postgresql support, programming shared hosting and dedicated hosting. +1-503-667-4564 - [EMAIL PROTECTED] - http://www.commandprompt.com Mammoth PostgreSQL Replicator. Integrated Replication for PostgreSQL begin:vcard fn:Joshua D. Drake n:Drake;Joshua D. org:Command Prompt, Inc. adr:;;PO Box 215;Cascade Locks;Oregon;97014;USA email;internet:[EMAIL PROTECTED] title:Consultant tel;work:503-667-4564 tel;fax:503-210-0034 note:Command Prompt, Inc. is the largest and oldest US based commercial PostgreSQL support provider. We provide the only commercially viable integrated PostgreSQL replication solution, but also custom programming, and support. We authored the book Practical PostgreSQL, the procedural language plPHP, and adding trigger capability to plPerl. x-mozilla-html:FALSE url:http://www.commandprompt.com/ version:2.1 end:vcard ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Call for 7.5 feature completion
plPHP and plPerlNG both belong on pgfoundry, not in the core distribution ... Uhhh?? Are you ripping out all core pls then? plPerlNG is supposed to replace plPerl, I was talking with Bruce and he seemed to think that (as long as the code was good enough) that we could incorporate plPHP??? Sincerely, Joshua D. Drake Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 -- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC Postgresql support, programming shared hosting and dedicated hosting. +1-503-667-4564 - [EMAIL PROTECTED] - http://www.commandprompt.com Mammoth PostgreSQL Replicator. Integrated Replication for PostgreSQL begin:vcard fn:Joshua D. Drake n:Drake;Joshua D. org:Command Prompt, Inc. adr:;;PO Box 215;Cascade Locks;Oregon;97014;USA email;internet:[EMAIL PROTECTED] title:Consultant tel;work:503-667-4564 tel;fax:503-210-0034 note:Command Prompt, Inc. is the largest and oldest US based commercial PostgreSQL support provider. We provide the only commercially viable integrated PostgreSQL replication solution, but also custom programming, and support. We authored the book Practical PostgreSQL, the procedural language plPHP, and adding trigger capability to plPerl. x-mozilla-html:FALSE url:http://www.commandprompt.com/ version:2.1 end:vcard ---(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] Call for 7.5 feature completion
Mario Weilguni wrote: Interesting. We have made COMPLETELY different experiences. There is one question people ask me daily: When can we have sychronous replication and PITR?. Performance is not a problem here. People are more interested in stability and enterprise features such as those I have mentioned above. I doubt that. Having deployed several 7.4 databases, the first customers ask (of course not in technical speech, but in the meaning) when the problem with checkpoint hogging system down is solved. This is a really serious issue, especially when using drbd + ext3. The system will become really unresponsive when checkpoint is running. I heavily await 7.5 because of the background writer. Have you done some more extensive tests with 7.5 already and if so, what are your experiences with it so far? Jan -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # ---(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] Call for 7.5 feature completion
Simon Riggs [EMAIL PROTECTED] writes: I can't complete by 1 June. Think worse of me if you choose. I'll mention another perspective as a user. I'm actually happier seeing a relatively minor release come out just before the big changes hit. If 7.5 has Windows, PITR, nested transactions, etc. especially if I see they went in just before a feature freeze then I'm liable to wait before I suggest installing it in production because it makes me fear the impact these major new features will have on a system that's been running fine on 7.4. Whereas if 7.5 comes out and is an incremental improvement over 7.4 with a background writer, more knobs to control checkpoints and vacuum, better sorted pg_dumps, etc, then I'm liable to install it right away. And I get to use these features while the big changes settle. From a user-perceptions point of view this is an even bigger factor when people start bandying about 8.0. A LOT of sysadmins are going to hold off on installing a release labelled 8.0 until they see 8.1 or 8.2. Sysadmins are an awfully superstitious bunch and numerology is popular. Moreover if PITR, the Windows port, nested transactions go into 7.6 or 8.0 right at the beginning of the development cycle and we have 3-4 months of working with databases running with these features I strongly suspect that the stability of the product will make a bigger long term impression than the rapid pace of new features arriving. So in my perfect world I picture 7.5 freezing June 1 and releasing in July or so, giving a nice reliable simple upgrade for people who just want a safe 7.x series to upgrade to even after 8.0 comes out. PITR, nested transactions going into the CVS tree sometime in June or July and being frozen as 8.0 towards the end of the year. -- greg ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Call for 7.5 feature completion
Greg Stark wrote: Simon Riggs [EMAIL PROTECTED] writes: I can't complete by 1 June. Think worse of me if you choose. ... So in my perfect world I picture 7.5 freezing June 1 and releasing in July or so, giving a nice reliable simple upgrade for people who just want a safe 7.x series to upgrade to even after 8.0 comes out. PITR, nested transactions going into the CVS tree sometime in June or July and being frozen as 8.0 towards the end of the year. A quick google of 7.4 Win32 release will reveal that the above was precisely what was said about 7.4: it would be released to not hold up important features like the IN optimization and a quick 7.5 would have Win32 and PITR. It's almost as if a cron job reposts this thread every 6 - 12 months. For those of us that are desirous of PITR, it's a 6 month reposting that is becoming painful to read... Mike Mascari ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Call for 7.5 feature completion
On Mon, 17 May 2004, Joshua D. Drake wrote: plPHP and plPerlNG both belong on pgfoundry, not in the core distribution ... Uhhh?? Are you ripping out all core pls then? plPerlNG is supposed to replace plPerl, I was talking with Bruce and he seemed to think that (as long as the code was good enough) that we could incorporate plPHP??? That is the plan ... unless someone knows a reason why they can't be built independently of the core? ecpg relies on the grammar files in core, but as far as I knew (please correct me if I'm wrong) the pls only rely on headers and libraries that get installed ... 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: [HACKERS] Call for 7.5 feature completion
Mike Mascari [EMAIL PROTECTED] writes: Greg Stark wrote: Simon Riggs [EMAIL PROTECTED] writes: I can't complete by 1 June. Think worse of me if you choose. ... So in my perfect world I picture 7.5 freezing June 1 and releasing in July or so, giving a nice reliable simple upgrade for people who just want a safe 7.x series to upgrade to even after 8.0 comes out. PITR, nested transactions going into the CVS tree sometime in June or July and being frozen as 8.0 towards the end of the year. A quick google of 7.4 Win32 release will reveal that the above was precisely what was said about 7.4: it would be released to not hold up important features like the IN optimization and a quick 7.5 would have Win32 and PITR. It's almost as if a cron job reposts this thread every 6 - 12 months. For those of us that are desirous of PITR, it's a 6 month reposting that is becoming painful to read... I'm not sure what your point is though. It's not like people with my attitude made the people writing code take any longer. In fact had we held off 7.4 for any of these features it would have been a disaster. Incidentally, I'm not suggesting rushing 7.6/8.0 out the door. I'm imagining a regular release cycle. My comments are more geared to the idea that having PITR, Nested Transactions, etc hit the tree early in the development cycle would be smoother than having them hit right at the end of the development cycle. Think of all the added bells and whistles PITR will be able to grow over the course of a whole release cycle. Instead of having a barebones see it works implementation we'll have a really polished system with lots of optional but appreciated features. Maybe better integration in third-party backup tools, maybe even standby databases or replication based on it. -- greg ---(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] Call for 7.5 feature completion
On Mon, 17 May 2004, Mike Mascari wrote: Greg Stark wrote: Simon Riggs [EMAIL PROTECTED] writes: I can't complete by 1 June. Think worse of me if you choose. ... So in my perfect world I picture 7.5 freezing June 1 and releasing in July or so, giving a nice reliable simple upgrade for people who just want a safe 7.x series to upgrade to even after 8.0 comes out. PITR, nested transactions going into the CVS tree sometime in June or July and being frozen as 8.0 towards the end of the year. A quick google of 7.4 Win32 release will reveal that the above was precisely what was said about 7.4: it would be released to not hold up important features like the IN optimization and a quick 7.5 would have Win32 and PITR. It's almost as if a cron job reposts this thread every 6 - 12 months. For those of us that are desirous of PITR, it's a 6 month reposting that is becoming painful to read... k, let's think this through ... 7.4 was released, what, 6 months ago? And 6 months later, PITR still isn't ready? Is there some logic here that if 7.4 wasn't released, PITR would have been done any sooner? 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] Call for 7.5 feature completion
Marc G. Fournier wrote: On Mon, 17 May 2004, Joshua D. Drake wrote: Personally, Win32, subtransactions and PITR are what we are after. Second would be inclusion of plPHP and plPerlNG which are arguably the most widely used languages to connect to PostgreSQL. plPHP and plPerlNG both belong on pgfoundry, not in the core distribution ... When are you going to pull PL/pgSQL, PL/python and PL/Tcl? Jan -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Call for 7.5 feature completion
Bruce Momjian wrote: Marc G. Fournier wrote: On Mon, 17 May 2004, Bruce Momjian wrote: Most hopefully this is very discouraging! Connection pools are a nice thing and I have used pgpool recently with great success, for pooling connections. But attempting to deliver multimaster replication as a byproduct of a connection pool isn't going to become an enterprise feature. And the more half-baked, half-functional and half-reliable replication attempts there are, the harder it will be to finally get a real solution being recognized. Well, considering we offer _nothing_ for multi-master right now, I think it is a valuable project. Connection pooling is *not* multi master ... it doesn't even simulate multi-master ... multi-master, at least as far as I'm aware, means no point of failure, and connection pooling creates a *single* point of failure ... the pgpool process dies, you've lost all connections to the database ... I think multi-master does nothing with free-from-single-point-of-failure. A multi-master replication system could have its own single point of failure (for example, some systems have single coordinate server). On the other hand single-master replication system could avoid single point of failure using some external mechanism (for example UltraMonkey). I think people are confusing pgpool with pgcluster. And you wonder where that's coming from, eh? Tatsuo is advertising pgpool as a synchronous replication system suitable for failover. Quoting from the pgpool-1.0 README: Please do not use the word failover for pgpool relication functionality. Failover means it could continue replication operation with alternative database. pgpool does not do that in replication mode. Instead it disconnect the failed DB and continues operation with healthy DB (with no replication, of course). That's why I use the word degeneration in pgpool's replication mode. pgpool could be used as a replication server. This allows real-time backuping of the database to avoid disk failures. pgpool sends exactly same query to each PostgreSQL servers to accomplish replication. So pgpool can be regarded as a synchronous replication server. Don't get me wrong, as said pgpool works great for the purpose I tested, the pooling. But statements like that are causing the confusion here. Could you tell me why above is confusing? If it's really confusing, I'm glad to enhance it. Or are you saying pgpool should not be regrard as having replicaton facility? Or you are saying that pgpool is too similar to PGCluster? PGCluster is a multi-master/multi-slave/sync relication system. pgpool is a single-master/single-slave/sync replication. There's a clear distinction. single vs. multi-master is a BIG difference and I have never stated that pgpool is a multi-master replication system. BTW, the reason why I developed pgpool with replication functionality is that there's no single perfect replication solution in the world. Here are my comments for officially released replicatin systems (from my own point of view, of course): 1) DBMirror: good: simple and easy to use. bad: can not handle too much traffic. cannot replicate large objects. 2) PGCluster: good: can handle failover and recovery. SELECT load balancing is really nice. bad: requries many PCs. update performance is not good. cannot replicate large objects. 3) pgpool: good: simple and easy to use. can replicate large objects. update performance is not too bad. bad: no load balancing, no failover. I'm interested in if Slony-I solves all these bad. I will try it when I have spare time. -- Tatsuo Ishii ---(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] Call for 7.5 feature completion
Marc G. Fournier wrote: On Mon, 17 May 2004, Joshua D. Drake wrote: plPHP and plPerlNG both belong on pgfoundry, not in the core distribution ... Uhhh?? Are you ripping out all core pls then? plPerlNG is supposed to replace plPerl, I was talking with Bruce and he seemed to think that (as long as the code was good enough) that we could incorporate plPHP??? That is the plan ... unless someone knows a reason why they can't be built independently of the core? ecpg relies on the grammar files in core, but as far as I knew (please correct me if I'm wrong) the pls only rely on headers and libraries that get installed ... They are not as independant as one might think. The core support for set returning functions is required before a PL can do it. Same was with cursors and same will be with subtransactions being the base for exception handling. People have been struggling with unloadable shared objects from another version due to elog changes, I can't imagine what kind of support horror we're creating with this now. The much I am for pulling stuff that does not belong into core, doing it just for the fun of cleaning up or trimming doesn't do. One of the major functions of CVS is that one can tag collections of revisions that together build a release, a known to be working snapshot of file revisions. If we completely lose the ability to tell what version of what PL, client interface or extension works with what version of the backend, we're losing some important detail here. Jan -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Call for 7.5 feature completion
The much I am for pulling stuff that does not belong into core, doing it just for the fun of cleaning up or trimming doesn't do. One of the major functions of CVS is that one can tag collections of revisions that together build a release, a known to be working snapshot of file revisions. If we completely lose the ability to tell what version of what PL, client interface or extension works with what version of the backend, we're losing some important detail here. Also, one of the best features of PostgreSQL is that you can, at will write a procedure in just about anything... It seems that keeping at least the most popular pl implementations would be an important step. ] Jan -- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC Postgresql support, programming shared hosting and dedicated hosting. +1-503-667-4564 - [EMAIL PROTECTED] - http://www.commandprompt.com PostgreSQL Replicator -- production quality replication for PostgreSQL ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Call for 7.5 feature completion
Joshua D. Drake wrote: Just to throw in my .02, plPerlNG won't be ready for testing until mid, later June either. Then there is also plPHP which although we haven't had any bug reports still needs some more peer review. Also we would like to submit our ECPG which includes SET DESCRIPTOR and error handling but that too needs more peer review. I assume your ecpg will be a patch to the existing ecpg rather than a new verion, right? -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (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] Call for 7.5 feature completion
He is waiting for nested transactions to be committed so he can merge his work in. Somebody has posted sync multimaster replication (PgCluster) - nobody has commented on that. Maybe I am the only one who has ever tried it ... I think it should be on gborg. You mean pgFoundry :) Chris ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Call for 7.5 feature completion
Marc G. Fournier wrote: On Mon, 17 May 2004, Joshua D. Drake wrote: plPHP and plPerlNG both belong on pgfoundry, not in the core distribution ... Uhhh?? Are you ripping out all core pls then? plPerlNG is supposed to replace plPerl, I was talking with Bruce and he seemed to think that (as long as the code was good enough) that we could incorporate plPHP??? That is the plan ... unless someone knows a reason why they can't be built independently of the core? ecpg relies on the grammar files in core, but as far as I knew (please correct me if I'm wrong) the pls only rely on headers and libraries that get installed ... Server-side languages are tied into the backend even closer than the user data types. They are best in the core distribution. We didn't put plR in core because it had a conflicting license. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (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: [HACKERS] Call for 7.5 feature completion
I assume your ecpg will be a patch to the existing ecpg rather than a new verion, right? Yes it is a patch against 7.4.2 J -- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC Postgresql support, programming shared hosting and dedicated hosting. +1-503-667-4564 - [EMAIL PROTECTED] - http://www.commandprompt.com PostgreSQL Replicator -- production quality replication for PostgreSQL
Re: [HACKERS] Call for 7.5 feature completion
On Mon, 17 May 2004, Bruce Momjian wrote: Server-side languages are tied into the backend even closer than the user data types. They are best in the core distribution. We didn't put plR in core because it had a conflicting license. So, they can live on their own, which is a good thing to know ... 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: [HACKERS] Call for 7.5 feature completion
On Mon, 17 May 2004, Jan Wieck wrote: They are not as independant as one might think. The core support for set returning functions is required before a PL can do it. Same was with cursors and same will be with subtransactions being the base for exception handling. People have been struggling with unloadable shared objects from another version due to elog changes, I can't imagine what kind of support horror we're creating with this now. k, how is this different then any other software package that has to be extended to make use of new features? For instance, when subtransactions get added, is that same person going to extended the various pls as well? Or, more likely, when subtransactions are added, will someone responsible for each of the pls submit patches to extend them? Having pl/pgsql included as a 'reference implementation' is reasonable ... I just think that pl/pick your language here should be on pgfoundry ... If we completely lose the ability to tell what version of what PL, client interface or extension works with what version of the backend, we're losing some important detail here. Why is it our responsibility to ensure that though? Shouldn't the developer (or group of developers) responsible for the PL/interface/extension be responsible for that? Let's use plPHP as an example here ... I'm going to guess that it supports PHP4, which is the 'standard' right now ... what about PHP5? If not, what happens in 3 months if/when that support is added? Do ppl using PHP5 have to wait until the next release of PostgreSQL before they can use it? If, instead, plPHP is on pgfoundry, there is nothing that stops them adopting a release numbering in parallel to the core distribution, at least in so far as major.minor ... but they could release a major.minor.minor release as required seperate from our release cycle that still matches our latest stable, but extends itself to working with PHP5, as an example ... The thing is, whether as part of core, or as a seperate project, *any* pl/interface/extension has to be maintained in order to be in sync ... if done as a seperate project, in parallel with core, it is at least possible to release on their own timelines in order to correct bugs, or add features ... as part of core, new features/bug fixes have to wait for all of core to be released ... 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: [HACKERS] Call for 7.5 feature completion
Marc G. Fournier wrote: On Mon, 17 May 2004, Mike Mascari wrote: A quick google of 7.4 Win32 release will reveal that the above was precisely what was said about 7.4: it would be released to not hold up important features like the IN optimization and a quick 7.5 would have Win32 and PITR. It's almost as if a cron job reposts this thread every 6 - 12 months. For those of us that are desirous of PITR, it's a 6 month reposting that is becoming painful to read... k, let's think this through ... 7.4 was released, what, 6 months ago? And 6 months later, PITR still isn't ready? Is there some logic here that if 7.4 wasn't released, PITR would have been done any sooner? Not being the author, I don't know. And in the case of PITR, the pre-7.4 author is different than the post-7.4 author. However, if I was personally responsible for holding up the release of a project due to a feature that I had vowed to complete, I would feel morally compelled to get it done. If I had then asked for, and was granted, an extra 15-30 days I would feel even more personally responsible and under greater pressure. If, however, the project made the release without waiting, I would feel simultaneously relieved and possibly a little bitter. Possibly a little bitter in that either what I was working on wasn't perceived as sufficiently valuable to hold up a release for 15-30 days, or that my word regarding the completion status was insufficient for the project to trust me. Let me reiterate the words possibly and little. But in open source projects, a developer willing to contribute hundreds, possibly thousands of hours of his own time is particularly invaluable. I can tell you that, in economic models that have studied human behavior with respect to unemployment insurance, for example, the re-employment rates are clustered at the tails: when someone is first unemployed and when the insurance is about to expire. It's an inappropriate analogy because the project lives on from release to release, instead of having a drop-dead date at which point no future changes would be made ad infinitum, but it paints a useful picture. I'm willing to bet that CVS commit rates mirror the above behavior. Unlike unemployment benefits, releasing the software without the feature essentially just extends the development period another 6 months, the work will intensify at the new perceived tails, and the process repeated. There are probably econometric papers that model the software development release cycle that could give quantitative arguments. I'm not arguing I'm right and your wrong, btw. I'm just pointing out some of the possibilities. In fact, for one developer it might be the code production maximizing condition to give them another 6 months and for another, creating the pressure associated with a 15-30 day extension where the world is standing still awaiting their patch... Mike Mascari ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Call for 7.5 feature completion
On Mon, 17 May 2004, Joshua D. Drake wrote: I assume your ecpg will be a patch to the existing ecpg rather than a new verion, right? Yes it is a patch against 7.4.2 Will you have one against -HEAD? I believe there have been changes since 7.5 was branched, no? Or have they been mostly cosmetic/docs? 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/faqs/FAQ.html
Re: [HACKERS] Call for 7.5 feature completion
Why is it our responsibility to ensure that though? Shouldn't the developer (or group of developers) responsible for the PL/interface/extension be responsible for that? Let's use plPHP as an example here ... I'm going to guess that it supports PHP4, which is the 'standard' right now ... what about PHP5? If not, what happens in 3 months if/when that support is added? Do ppl using PHP5 have to wait until the next release of PostgreSQL before they can use it? Actually this is a pretty good example. Yes right now it supports PHP4, it will support PHP5 when PHP5 is ready. And of course, no they would not have to wait. They could download and patch against the current source tree... The thing is, whether as part of core, or as a seperate project, *any* pl/interface/extension has to be maintained in order to be in sync ... if done as a seperate project, in parallel with core, it is at least possible to release on their own timelines in order to correct bugs, or add features ... as part of core, new features/bug fixes have to wait for all of core to be released ... Well actually no, because of the above mentioned. Even if plPHP is on pgFoundry... there is no reason why a README couldn't be included in the src/pl/plphp directory that says: look here for the latest release etc... Sincerely, Joshua D. Drake 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 -- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC Postgresql support, programming shared hosting and dedicated hosting. +1-503-667-4564 - [EMAIL PROTECTED] - http://www.commandprompt.com PostgreSQL Replicator -- production quality replication for 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: [HACKERS] Call for 7.5 feature completion
Marc G. Fournier wrote: On Mon, 17 May 2004, Joshua D. Drake wrote: I assume your ecpg will be a patch to the existing ecpg rather than a new verion, right? Yes it is a patch against 7.4.2 Will you have one against -HEAD? I believe there have been changes since 7.5 was branched, no? Or have they been mostly cosmetic/docs? Josh just sent me the patch and it looks good. I encouraged him to send it over to Michael Meskes, and soon, especially if he wants it in 7.5. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (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: [HACKERS] Call for 7.5 feature completion
Bruce Momjian said: Marc G. Fournier wrote: On Mon, 17 May 2004, Joshua D. Drake wrote: plPHP and plPerlNG both belong on pgfoundry, not in the core distribution ... Uhhh?? Are you ripping out all core pls then? plPerlNG is supposed to replace plPerl, I was talking with Bruce and he seemed to think that (as long as the code was good enough) that we could incorporate plPHP??? That is the plan ... unless someone knows a reason why they can't be built independently of the core? ecpg relies on the grammar files in core, but as far as I knew (please correct me if I'm wrong) the pls only rely on headers and libraries that get installed ... Server-side languages are tied into the backend even closer than the user data types. They are best in the core distribution. We didn't put plR in core because it had a conflicting license. I would never have created the plperlNG project on pgfoundry if I had thought it meant divorcing plperl from the core. pgfoundry in my mind can be a home for projects that will eventually fold into the core, as well as things that will always remain separate. I agree with Bruce about the place of server-side PLs. cheers andrew ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Call for 7.5 feature completion
Marc G. Fournier wrote: A quick google of 7.4 Win32 release will reveal that the above was precisely what was said about 7.4: it would be released to not hold up important features like the IN optimization and a quick 7.5 would have Win32 and PITR. It's almost as if a cron job reposts this thread every 6 - 12 months. For those of us that are desirous of PITR, it's a 6 month reposting that is becoming painful to read... k, let's think this through ... 7.4 was released, what, 6 months ago? And 6 months later, PITR still isn't ready? Is there some logic here that if 7.4 wasn't released, PITR would have been done any sooner? Even though I was for a later feature freeze, Marc argument is powerful. There was talk that Win32 and PITR would be available right after 7.5 started development, and they weren't. Instead it took several months for Patrick and Tom to get JR's PITR/WAL patch into CVS, and then another month or two for someone to appear and do the work of archiving the files, then after discussion of implementation issues, it now needs even more work. Win32 has been on a steady course thanks to Claudio and Magnus --- without them we would be nowhere near finished. Nested transactions were started in April and tablespaces in February, both funded by Fujitsu. Basically, maybe Marc is right that these features have to span multiple releases. Win32 spanned two releases (some of it was in 7.4). PITR WAL was initially done by JR just before 7.3 feature freeze, I think, but it took all this time to get this far. Basically, my big concern is incremental improvement releases, which I feel describe our past few releases. Yes, I said it. I see items listed above as critical to allowing PostgreSQL to move into more significant roles in enterprises, and I am frustrated that it is taking so long to happen. What can be done? Well, money from Fujitsu and other companies (Afilias/Sloney, Command Prompt/ecpg-plPHP), is allowing us to hit some of these bigger items, so hopefully that will move us forward in these complex areas. I am not sure what could have been done to push some of these projects along faster. I am happy Win32 had a steady pace of improvement, but even now we are finishing up to the wire rather than having it done months ago, but in hindsight, I am not sure what we could have done differently. So, yea, I am frustrated. I know these features are hard and complex, but I want them for PostgreSQL, and I want them as soon as possible. I guess what really bugs me is that we are so close to having these few remaining big features, and because they are so complex, they are taking a lot longer to arrive than previous features, and sometimes see a year pass without progress on some items, and that bugs me. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (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] Call for 7.5 feature completion
On Mon, May 17, 2004 at 17:06:18 -0400, Greg Stark [EMAIL PROTECTED] wrote: I'll mention another perspective as a user. I'm actually happier seeing a relatively minor release come out just before the big changes hit. If 7.5 has Windows, PITR, nested transactions, etc. especially if I see they went in just before a feature freeze then I'm liable to wait before I suggest installing it in production because it makes me fear the impact these major new features will have on a system that's been running fine on 7.4. 7.5 has already had some significant changes made in how writes are done to disk. If I had very valuable data to protect I would already consider 7.5 a risky upgrade (in comparison to the 7.3 to 7.4 upgrade). If this is your situation, going to 7.4.3 and sticking with it for a while waiting to see how 7.5 does, may be a good idea. ---(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] Call for 7.5 feature completion
So, yea, I am frustrated. I know these features are hard and complex, but I want them for PostgreSQL, and I want them as soon as possible. I guess what really bugs me is that we are so close to having these few remaining big features, and because they are so complex, they are taking a lot longer to arrive than previous features, and sometimes see a year pass without progress on some items, and that bugs me. So why do we wait for some of these features? The bgwriter is done right? Why don't we backport to 7.4.x and release with 7.4.3? What about the vacuum stuff Jan was doing? I guess what I am saying is, what features are in HEAD that can be backported to 7.4.x without the requiring of an initdb? Yes it would be breaking from the tradition of very little feature releases in incrementals but then again maybe that would be a good thing... Sincerely, Joshua D. Drkae -- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC Postgresql support, programming shared hosting and dedicated hosting. +1-503-667-4564 - [EMAIL PROTECTED] - http://www.commandprompt.com PostgreSQL Replicator -- production quality replication for PostgreSQL ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Call for 7.5 feature completion
On Mon, 17 May 2004, Joshua D. Drake wrote: So, yea, I am frustrated. I know these features are hard and complex, but I want them for PostgreSQL, and I want them as soon as possible. I guess what really bugs me is that we are so close to having these few remaining big features, and because they are so complex, they are taking a lot longer to arrive than previous features, and sometimes see a year pass without progress on some items, and that bugs me. So why do we wait for some of these features? The bgwriter is done right? Why don't we backport to 7.4.x and release with 7.4.3? What about the vacuum stuff Jan was doing? I guess what I am saying is, what features are in HEAD that can be backported to 7.4.x without the requiring of an initdb? Yes it would be breaking from the tradition of very little feature releases in incrementals but then again maybe that would be a good thing... This has been put forward by me a couple of times in the past, and, to a small extent, I do agree with the arguments against it ... namely, the backporting, testing and release cycles that we'd have to adopt would detract from forward development ... As soon as we get to backporting features, then we have to get into feature freezes on the stable branch, beta periods of testing leading to a release, etc ... I'd almost say that time would be better spent on coming up with an effective upgrade method so that upgrading to new releases is easier ... Please note that I'm not against the backporting, but do understand the arguments against it in terms of time and manpower ... 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: [HACKERS] Call for 7.5 feature completion
On Mon, May 17, 2004 at 04:55:50PM +0200, Zeugswetter Andreas SB SD wrote: It is too late to think about pushing back another month. We had this discussion already. June 1 is it. I thought the outcome of that discussion was June 15 ? I think there was no outcome. There was no official pronouncement, there was no vote, there was no consensus. People seemed to stick with whatever was closer. Can we try to do the 2PC patch now instead of waiting for subtransactions ? The last post from Heikki I read said that he discovered some serious problems with his implementation and he wanted do rethink about them. I don't think he will be able to make it, mainly because if my patch gets accepted it will be too close to feature freeze (if it is June 1st). Personally I've been focused on getting subtransactions done and now I think I'm very close to an acceptable patch, but what has slowed me down the last time has been lack of feedback from core developers. It was feedback I needed to figure out the best ways to do things (I made several big mistakes that I'm only now correcting thanks to invaluable comments from Tom Lane), and without it the last steps were getting very difficult to me. Fortunately now I've got it. I have some confidence in that I will be able to deliver it maybe the last week of May. I can only hope, however, that it will not be rejected because it's presented too close to feature freeze. That would be a shame, because I offered incremental patches a lot of time ago and they weren't even looked at (Hey, I'm not blaming anyone). -- Alvaro Herrera ([EMAIL PROTECTED]) FOO MANE PADME HUM ---(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] Call for 7.5 feature completion
Alvaro Herrera Munoz wrote: Personally I've been focused on getting subtransactions done and now I think I'm very close to an acceptable patch, but what has slowed me down the last time has been lack of feedback from core developers. It was feedback I needed to figure out the best ways to do things (I made several big mistakes that I'm only now correcting thanks to invaluable comments from Tom Lane), and without it the last steps were getting very difficult to me. Fortunately now I've got it. I have some confidence in that I will be able to deliver it maybe the last week of May. I can only hope, however, that it will not be rejected because it's presented too close to feature freeze. That would be a shame, because I offered incremental patches a lot of time ago and they weren't even looked at (Hey, I'm not blaming anyone). One huge problem is that many features are asking for our attention this close to freeze date. I spend some time on relative-path installs, and now there are lots of patches that need to be reviewed and placed into the queue, and we haven't been giving you enough feedback. And I am thinking of helping with PITR because there isn't much work to do except plugging into the backend and GUC. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (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: [HACKERS] Call for 7.5 feature completion
Not being the author, I don't know. And in the case of PITR, the pre-7.4 author is different than the post-7.4 author. However, if I was personally responsible for holding up the release of a project due to a feature that I had vowed to complete, I would feel morally compelled to get it done. If I had then asked for, and was granted, an extra 15-30 days I would feel even more personally responsible and under greater pressure. If, however, the project made the release without waiting, I would feel simultaneously relieved and possibly a little bitter. Possibly a little bitter in that either what I was working on wasn't perceived as sufficiently valuable to hold up a release for 15-30 days, or that my word regarding the completion status was insufficient for the project to trust me. Let me reiterate the words possibly and little. But in open source projects, a developer willing to contribute hundreds, possibly thousands of hours of his own time is particularly invaluable. I can tell you that, in economic models that have studied human behavior with respect to unemployment insurance, for example, the re-employment rates are clustered at the tails: when someone is first unemployed and when the insurance is about to expire. It's an inappropriate analogy because the project lives on from release to release, instead of having a drop-dead date at which point no future changes would be made ad infinitum, but it paints a useful picture. I'm willing to bet that CVS commit rates mirror the above behavior. Unlike unemployment benefits, releasing the software without the feature essentially just extends the development period another 6 months, the work will intensify at the new perceived tails, and the process repeated. There are probably econometric papers that model the software development release cycle that could give quantitative arguments. I'm not arguing I'm right and your wrong, btw. I'm just pointing out some of the possibilities. In fact, for one developer it might be the code production maximizing condition to give them another 6 months and for another, creating the pressure associated with a 15-30 day extension where the world is standing still awaiting their patch... Mike Mascari Yesterday I have issued a posting which had to do with motivation. This is Open Source - there is no boss which tells somebody to finish something. Therefore we must MOTIVATE people. Has anybody read Sim Riggs posting earlier in the thread. There is one paragraph which makes my alarm bells ring VERY LOUD: This is all rather disheartening, having laid out a time plan months back, noting some of this. Yes, I am working on it, and no, I'm not hand waving, but I do take time off every million keystrokes or so. If somebody who has done a GREAT JOB is disheartened by the way his work is treated it is really time to start thinking ... From my very personal point of view Mike absolutely right; why not give it a try. I guess Simon and Alvaro deserve some more time and we should give those guys a limited time frame to finish their work. Recall, it's all about motivation ... Regards, Hans -- Cybertec Geschwinde u Schoenig Schoengrabern 134, A-2020 Hollabrunn, Austria Tel: +43/720/10 1234567 or +43/664/233 90 75 www.cybertec.at, www.postgresql.at, kernel.cybertec.at ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Call for 7.5 feature completion
Am Monday 17 May 2004 22:42 schrieb Jan Wieck: I doubt that. Having deployed several 7.4 databases, the first customers ask (of course not in technical speech, but in the meaning) when the problem with checkpoint hogging system down is solved. This is a really serious issue, especially when using drbd + ext3. The system will become really unresponsive when checkpoint is running. I heavily await 7.5 because of the background writer. Have you done some more extensive tests with 7.5 already and if so, what are your experiences with it so far? Not really yet, I've installed 7.5 on a development machine yesterday, changed to JFS filesystem, and so far the system feels more responsive, but I've yet to test it. 7.5 on my personal PC performed very fine, especially with some more problematic queries it produced better query plans. Regards, Mario Weilguni ---(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] Call for 7.5 feature completion
Well that seems to be part of the problem. ext3 does not scale well at all under load. You should probably upgrade to a better FS (like XFS). I am not saying that your point isn't valid (it is) but upgrading to a better FS will help you. Thanks for the info, but I've already noticed that. XFS is no option since it does not work with drbd, but jfs seems to be quite good. Regards, Mario Weilguni ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Call for 7.5 feature completion
From the FAQ (http://www.drbd.org/316.html): Q: Can XFS be used with DRBD? A: XFS uses dynamic block size, thus DRBD 0.7 or later is needed. Hope we're talking about the same project. ;) Cheers! On Tue, 2004-05-18 at 00:16, Mario Weilguni wrote: Well that seems to be part of the problem. ext3 does not scale well at all under load. You should probably upgrade to a better FS (like XFS). I am not saying that your point isn't valid (it is) but upgrading to a better FS will help you. Thanks for the info, but I've already noticed that. XFS is no option since it does not work with drbd, but jfs seems to be quite good. Regards, Mario Weilguni ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings -- Greg Copeland, Owner [EMAIL PROTECTED] Copeland Computer Consulting 940.206.8004 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Call for 7.5 feature completion
Bruce Momjian wrote: Tom Lane wrote: Marc G. Fournier [EMAIL PROTECTED] writes: On Thu, 29 Apr 2004, Tom Lane wrote: In the first place it's unfair to other developers to make schedule slips at the last moment, and especially to *plan* to do so. Isn't it equally unfair to slip the scheduale that developers that have been working on some large features (PITR, 2PC immediately coming to mind) have been working towards based on a deadline? If Win32 that much more important then those other features? As you well know, I have no use for the Win32 port at all ;-). However, of the major features that Bruce just listed, the Win32 port is the only one I consider really likely to appear in 7.5; sure it needs major work yet, but the others are still in the vaporware-till-proven-otherwise category. Certainly they are not solid enough to justify making schedule decisions on the basis of this will probably be ready by date X. I am willing to adjust the freeze deadline now to make it more probable that at least one of those major features will really make it into 7.5. The realities are that the Win32 port should determine any such schedule decision, because nothing else is close enough to the finish line to justify considering its needs instead. I guess my point is really do you want to freeze on June 1 if *none* of these features are done? Yep, my point too, that we need X big features to schedule beta, and we don't have any yet. I believe PITR actually does work as Simon has tested it, and we have the code. Of course, i am discussing how it should be integrated, but I do believe it works. And I think Gavin will complete his tablespaces, perhaps with our help. We have ARC, the background writer and vacuum delay, and people even ask me for backports of that (I have one for vacuum delay, but refuse to make one for the others). How long do you want to delay that being ready for production? Do you really think people that are suffering from the fact that checkpoints, vacuum runs and pg_dumps bog down their machines to the state where simple queries take several seconds care that much for any Win32 port? Do you think it is a good sign for those who have been our traditional Unix user base that we delay the important enhancements that they need because we want to attract a lot of non-professional users in Windows land? I think that is the wrong signal to send. However important for marketing the Win32 port is, there are other things in the pipeline that are important for those users we have won already long time ago. Let's rather not lose them. Jan -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Call for 7.5 feature completion
Jan Wieck wrote: We have ARC, the background writer and vacuum delay, and people even ask me for backports of that (I have one for vacuum delay, but refuse to make one for the others). How long do you want to delay that being ready for production? Do you really think people that are suffering from the fact that checkpoints, vacuum runs and pg_dumps bog down their machines to the state where simple queries take several seconds care that much for any Win32 port? Do you think it is a good sign for those who have been our traditional Unix user base that we delay the important enhancements that they need because we want to attract a lot of non-professional users in Windows land? I think that is the wrong signal to send. However important for marketing the Win32 port is, there are other things in the pipeline that are important for those users we have won already long time ago. Let's rather not lose them. Sure those are nifty enhancements, but they are not really new features. I would rather call them performance enhancements. Sure, there are some folks who can't use PostgreSQL without them, but they are not like PITR or nested transactions where you really can't easily work around the limitation. Sure, you can work around the lack of a Win32 port with Cygwin, and maybe use replication in place of PITR, but the big question is are you hitting a large precentage of users with an enhancement. I am sure i can get some me too's for your improvements, but it doesn't represeent dramatic new functionality for PostgreSQL. I personally don't think Win32 is enough of a new feature either, but others disagree. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (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: [HACKERS] Call for 7.5 feature completion
Bruce Momjian kirjutas P, 16.05.2004 kell 22:45: Jan Wieck wrote: We have ARC, the background writer and vacuum delay, and people even ask me for backports of that (I have one for vacuum delay, but refuse to make one for the others). How long do you want to delay that being ready for production? Do you really think people that are suffering from the fact that checkpoints, vacuum runs and pg_dumps bog down their machines to the state where simple queries take several seconds care that much for any Win32 port? Do you think it is a good sign for those who have been our traditional Unix user base that we delay the important enhancements that they need because we want to attract a lot of non-professional users in Windows land? I think that is the wrong signal to send. However important for marketing the Win32 port is, there are other things in the pipeline that are important for those users we have won already long time ago. Let's rather not lose them. Sure those are nifty enhancements, but they are not really new features. I would rather call them performance enhancements. But it seems that they _are_ new enough features not to be included in point releases (like 7.4.3). Sure, there are some folks who can't use PostgreSQL without them, but they are not like PITR or nested transactions where you really can't easily work around the limitation. If you need a 24h non-stop database for global business, it is not acceptable to have 30-minute periods of very slow queries resulting in dropped connections. The only way to work around it without Jan's patches is not to run vacuum at all, but this is a lousy longer-term solution. Sure, you can work around the lack of a Win32 port with Cygwin, and maybe use replication in place of PITR, but the big question is are you hitting a large precentage of users with an enhancement. I'm not sure that the initial version of PITR will be a good replacement for replication. I am sure i can get some me too's for your improvements, but it doesn't represeent dramatic new functionality for PostgreSQL. For me the vacuum delay *does* represent a dramatic new functionality and I was quite disappointed that the simple version did not make it into 7.4. I personally don't think Win32 is enough of a new feature either, but others disagree. --- Hannu ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Call for 7.5 feature completion
Hannu Krosing wrote: Sure, you can work around the lack of a Win32 port with Cygwin, and maybe use replication in place of PITR, but the big question is are you hitting a large precentage of users with an enhancement. I'm not sure that the initial version of PITR will be a good replacement for replication. I am sure i can get some me too's for your improvements, but it doesn't represeent dramatic new functionality for PostgreSQL. For me the vacuum delay *does* represent a dramatic new functionality and I was quite disappointed that the simple version did not make it into 7.4. Agreed, but you are a me too, not a huge percentage of our userbase. Basically, after 6-7 months of development, I want more than a vacuum patch and a new cache replacement policy. I want something big, in fact, several big things. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (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: [HACKERS] Call for 7.5 feature completion
On Sun, 16 May 2004, Bruce Momjian wrote: I personally don't think Win32 is enough of a new feature either, but others disagree. Jan, correct me if I'm wrong ... Jan's point is that we have enough already to warrant a beta on June 1st, even without Win32 ... Win32 (or any of the other stuff, like PITR/tablespaces) would be icing on the cake ... 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: [HACKERS] Call for 7.5 feature completion
Jan, correct me if I'm wrong ... Jan's point is that we have enough already to warrant a beta on June 1st, even without Win32 ... Win32 (or any of the other stuff, like PITR/tablespaces) would be icing on the cake ... I think we're close enough on win32 to wait for it. It would look bad for us to miss inclusion of win32 two releases in a row... Chris ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Call for 7.5 feature completion
On Sun, 2004-05-16 at 23:02, Marc G. Fournier wrote: On Sun, 16 May 2004, Bruce Momjian wrote: I personally don't think Win32 is enough of a new feature either, but others disagree. Jan, correct me if I'm wrong ... Jan's point is that we have enough already to warrant a beta on June 1st, even without Win32 ... Win32 (or any of the other stuff, like PITR/tablespaces) would be icing on the cake I have no use for Win32 support but it would hurt to have that particular feature pushed back again. ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Call for 7.5 feature completion
Marc G. Fournier wrote: On Sun, 16 May 2004, Bruce Momjian wrote: I personally don't think Win32 is enough of a new feature either, but others disagree. Jan, correct me if I'm wrong ... Jan's point is that we have enough already to warrant a beta on June 1st, even without Win32 ... Win32 (or any of the other stuff, like PITR/tablespaces) would be icing on the cake ... I disagree we have enough new features for a release, even with Win32. Our features are getting more complex and require more time to develop. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (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] Call for 7.5 feature completion
On Sun, 16 May 2004, Bruce Momjian wrote: Hannu Krosing wrote: Sure, you can work around the lack of a Win32 port with Cygwin, and maybe use replication in place of PITR, but the big question is are you hitting a large precentage of users with an enhancement. I'm not sure that the initial version of PITR will be a good replacement for replication. I am sure i can get some me too's for your improvements, but it doesn't represeent dramatic new functionality for PostgreSQL. For me the vacuum delay *does* represent a dramatic new functionality and I was quite disappointed that the simple version did not make it into 7.4. Agreed, but you are a me too, not a huge percentage of our userbase. How do you know? Have you polled our complete userbase? Basically, after 6-7 months of development, I want more than a vacuum patch and a new cache replacement policy. I want something big, in fact, several big things. Most likely won't happen, since what is considered big by you isn't necessarily what is considered big by someone else ... as Hannu, and I believe, Jan, have so far pointed out to you ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Call for 7.5 feature completion
On Mon, 17 May 2004, Bruce Momjian wrote: Marc G. Fournier wrote: On Sun, 16 May 2004, Bruce Momjian wrote: I personally don't think Win32 is enough of a new feature either, but others disagree. Jan, correct me if I'm wrong ... Jan's point is that we have enough already to warrant a beta on June 1st, even without Win32 ... Win32 (or any of the other stuff, like PITR/tablespaces) would be icing on the cake ... I disagree we have enough new features for a release, even with Win32. Our features are getting more complex and require more time to develop. Not true ... you just have to fix your definition of what a feature is ... a feature is an improvement to the system, whether it be new functionality, or improved performance ... I consider the work Tom did on the IN performance in 7.4 to have been a major feature, considering that it made use of it *alot* more effective ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Call for 7.5 feature completion
Marc G. Fournier wrote: On Mon, 17 May 2004, Bruce Momjian wrote: Marc G. Fournier wrote: On Sun, 16 May 2004, Bruce Momjian wrote: I personally don't think Win32 is enough of a new feature either, but others disagree. Jan, correct me if I'm wrong ... Jan's point is that we have enough already to warrant a beta on June 1st, even without Win32 ... Win32 (or any of the other stuff, like PITR/tablespaces) would be icing on the cake ... I disagree we have enough new features for a release, even with Win32. Our features are getting more complex and require more time to develop. Not true ... you just have to fix your definition of what a feature is ... a feature is an improvement to the system, whether it be new functionality, or improved performance ... I consider the work Tom did on the IN performance in 7.4 to have been a major feature, considering that it made use of it *alot* more effective ... See my recent email. You are stating that all features are of equal significance. Basically, the important missing features are also the ones the require the most work to complete. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (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: [HACKERS] Call for 7.5 feature completion
Marc G. Fournier wrote: Agreed, but you are a me too, not a huge percentage of our userbase. How do you know? Have you polled our complete userbase? Basically, after 6-7 months of development, I want more than a vacuum patch and a new cache replacement policy. I want something big, in fact, several big things. Most likely won't happen, since what is considered big by you isn't necessarily what is considered big by someone else ... as Hannu, and I believe, Jan, have so far pointed out to you ... I can't poll for everything. I make my own educated guesses. For a small percentage, vacuum delay and ARC are significant. For a larger percentage, PITR, Win32, tablespaces, and nested transactions are significant. I don't need to take a poll for that, and a me too doesn't change that fact. To say otherwise is to pretend that all our enhancements are of equal significance. Sure, for a given individual some are very important, but in the aggregate things are pretty easy to guess. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (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: [HACKERS] Call for 7.5 feature completion
On Mon, May 17, 2004 at 01:53:19 -0300, Marc G. Fournier [EMAIL PROTECTED] wrote: Not true ... you just have to fix your definition of what a feature is ... a feature is an improvement to the system, whether it be new functionality, or improved performance ... I consider the work Tom did on the IN performance in 7.4 to have been a major feature, considering that it made use of it *alot* more effective ... Personally, I found the 7.4 prebeta had a number of minor features that I wanted. So far I haven't seen many things of particular interest to me in 7.5. I haven't played with it yet, since there has been what appears to be some pretty significant changes in some fundemental parts of 7.5 and as such there appears to be more risk than there was at this point in 7.4s release cycle. Based on what I read about several of the big projects, it seems like the difference between a June 1 beta and a July 1 beta is worth taking the extra month to have a better chance at getting some of these projects in. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Call for 7.5 feature completion
On Mon, 17 May 2004, Bruce Momjian wrote: See my recent email. You are stating that all features are of equal significance. Basically, the important missing features are also the ones the require the most work to complete. Agreed ... and the ones that require the most work to complete *will* span multiple releases in between if they have to ... just because something doesn't make it into 7.5 doesn't mean that the developer is going to drop all their work and start from scratch hoping to make it into 7.6 ... 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: [HACKERS] Call for 7.5 feature completion
On Mon, 17 May 2004, Bruce Momjian wrote: Marc G. Fournier wrote: Agreed, but you are a me too, not a huge percentage of our userbase. How do you know? Have you polled our complete userbase? Basically, after 6-7 months of development, I want more than a vacuum patch and a new cache replacement policy. I want something big, in fact, several big things. Most likely won't happen, since what is considered big by you isn't necessarily what is considered big by someone else ... as Hannu, and I believe, Jan, have so far pointed out to you ... I can't poll for everything. I make my own educated guesses. Based on what though? All the clients that I deal with on a daily basis generally care about is performance ... that is generally what they upgrade for ... so, my 'educated guess' based on real world users is that Win32, PITR and nested transactions are not important ... tablespaces, I have one client that has asked about something *similar* to it, but tablespaces, for him, doesn't come close to what they would like to see ... So, my 'educated guess' is different then yours is ... does that make yours wrong? Nope ... just means we have different sample sets to work with ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Call for 7.5 feature completion
On Mon, 17 May 2004, Bruno Wolff III wrote: On Mon, May 17, 2004 at 01:53:19 -0300, Marc G. Fournier [EMAIL PROTECTED] wrote: Not true ... you just have to fix your definition of what a feature is ... a feature is an improvement to the system, whether it be new functionality, or improved performance ... I consider the work Tom did on the IN performance in 7.4 to have been a major feature, considering that it made use of it *alot* more effective ... Personally, I found the 7.4 prebeta had a number of minor features that I wanted. So far I haven't seen many things of particular interest to me in 7.5. I haven't played with it yet, since there has been what appears to be some pretty significant changes in some fundemental parts of 7.5 and as such there appears to be more risk than there was at this point in 7.4s release cycle. Based on what I read about several of the big projects, it seems like the difference between a June 1 beta and a July 1 beta is worth taking the extra month to have a better chance at getting some of these projects in. Key words: better chance ... it doesn't mean that *any* of them will get done even in that extra month, you are speculating that that one month will make a difference. Then, when that month is up, and nothing does materialize (devil's advocate here), do we add another month to 'have a better chance'? Where does it end? 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
