Thread: internal voting
Hello everybody, After Marc Fournier commented, it is time for pgaccess.org to make a decision. It is clear the project needs the following tools. - web site - mailing list(s) - cvs - bug tracking system It is clear, that there is a small new group with fresh desire to contribute in a dedicated way. It is clear, that pgaccess has only one meaning and this is PostgreSQL. It is clear, that the PostgreSQL core team is very supportive. It is clear, that pgaccess.org efforts can not result in anything good without a close collaboration with the PostgreSQL core team. Now, when we heard many different opinions, the question is - what is the best decision of organization. I would make the following summary, please, send your comments - SUMMARY 1] In terms of infrastructure, a separate web site, mailing list(s) and bug tracking system will increase the flexibility of the pgaccess team and will not create additional (and not very useful) burden for the PostgreSQL core team. The pgaccess is a tool - it is not an integral part of PostgreSQL and does not need day-to-day sharing. In the beginning it will be developed rather for the stable, than for the future versions of PostgreSQL. 2] It is clear that there must be one master copy of the CVS. The possibilities are two - this copy is kept with PostgreSQL or this copy is kept with pgaccess.org If the PostgreSQL core team can provide a CVS repository with similar flexibility to that it would have being based on the pgaccess.org server - I would vote for a PostgreSQL hosted CVS. This will be the naval cord between the two projects. 3] Still - the only thing that is not clear to me is - who is going to collect all patches and make one whole form them. As long as each of us works on a different thing - this should not be a big problem, but still - needs to be one person. Iavor -- www.pgaccess.org
On Fri, 10 May 2002 10:58:28 +0200 "Iavor Raytchev" <iavor.raytchev@verysmall.org> wrote: > Hello everybody, > > After Marc Fournier commented, it is time for pgaccess.org to make a > decision. > > It is clear the project needs the following tools. > > - web site > - mailing list(s) > - cvs > - bug tracking system > > It is clear, that there is a small new group with fresh desire to > contribute in a dedicated way. > > It is clear, that pgaccess has only one meaning and this is PostgreSQL. > > It is clear, that the PostgreSQL core team is very supportive. > > It is clear, that pgaccess.org efforts can not result in anything good > without a close collaboration with the PostgreSQL core team. > > Now, when we heard many different opinions, the question is - what is > the best decision of organization. > > I would make the following summary, please, send your comments - > > > SUMMARY > > 1] In terms of infrastructure, a separate web site, mailing list(s) and > bug tracking system will increase the flexibility of the pgaccess team > and will not create additional (and not very useful) burden for the > PostgreSQL core team. The pgaccess is a tool - it is not an integral > part of PostgreSQL and does not need day-to-day sharing. In the > beginning it will be developed rather for the stable, than for the > future versions of PostgreSQL. > > 2] It is clear that there must be one master copy of the CVS. The > possibilities are two - this copy is kept with PostgreSQL or this copy > is kept with pgaccess.org > > If the PostgreSQL core team can provide a CVS repository with similar > flexibility to that it would have being based on the pgaccess.org server > - I would vote for a PostgreSQL hosted CVS. This will be the naval cord > between the two projects. > > 3] Still - the only thing that is not clear to me is - who is going to > collect all patches and make one whole form them. As long as each of us > works on a different thing - this should not be a big problem, but still > - needs to be one person. > This looks all good to me, except I have one question: How will pgaccess be distributed? Personally, I like the idea that PG comes with pgaccess in the distribution, so I would hate to see that go away. Even though there are people that don't use pgaccess, it is always nice to have a default tool that comes with PG (yes, I know there is psql). --brett p.s. I am willing to help out as well...
[Note, I've changed the headers so everyone on the original distribution list is getting a copy via Bcc, including -hackers. It was the simplest way I could think of making certain the discussion moved to -interfaces as Marc requested.] On Sat, 11 May 2002, Bartus Levente wrote: > ... I think, there is no connection (should not be) > between the versions of the pgaccess and the versions of the pgsql. > Pgaccess is a visual tool for pgsql, that can be developed freely > without having anything to do with the pgsql developement. Yes. > So I cannot understand why the majority of the oppinions says that > pgaccess should stay in the shadow of the pgsql. Who said shadow? FWIW, I'd never have bothered about pgaccess, that's even I'd even known about it, if it hadn't come in the main postgres tree. > Breaking this tight connection we can help pgaccess to develop as fast > as it can, and we let free space for other projects to appear. For me > the first thing is to make my daily job as good and fast as I can. And > this is much easier with using the best tool for the particular > problem. This is why I started to make patches to this project. > Sorry but I can't wait for the next pgsql release to have this patches > included in the package. Uhoh, now we have a problem, unless your version is going to form the initial repository or there's little or no impact across the preexisting code. -- Nigel J. Andrews Director --- Logictree Systems Limited Computer Consultants
Iavor Raytchev writes: > 3] Still - the only thing that is not clear to me is - who is going to > collect all patches and make one whole form them. As long as each of us > works on a different thing - this should not be a big problem, but still - > needs to be one person. As far as I'm concerned, there is no need to change anything. If someone has patches for pgaccess, send them to -patches and they will be applied. When a new release of PostgreSQL happens, a new pgaccess will be distributed. Simple enough. If and when patches for pgaccess appear in significant numbers and for some reason, which I cannot imagine, this procedure doesn't end up being practical, we can consider the alternatives. But before you spend a lot of time building a new infrastructure, let's see some code. -- Peter Eisentraut peter_e@gmx.net
> If and when patches for pgaccess appear in significant numbers and for > some reason, which I cannot imagine, this procedure doesn't end up being > practical, we can consider the alternatives. But before you spend a lot > of time building a new infrastructure, let's see some code. > > -- > Peter Eisentraut peter_e@gmx.net We are working on it, because we have some code. Don't you believe us, or do you think we have a lot of free time to waste? We - Chris, Bartus, Boyan and myself, have enough patches we want to merge. And we do not feel like asking for permisson to do it. We sent them to Teo and we were asked by Teo to meet and see what we can do with our patches. And we were nice enough to tell the world about this. I do not feel neither like 'asking for permisson', nor like 'proving' anything. If somebody wants to help - is welcome. I think the discussion is over. We have some work to do. Iavor
On Fri, May 10, 2002 at 11:24:40PM +0200, Peter Eisentraut wrote: > Iavor Raytchev writes: > > > 3] Still - the only thing that is not clear to me is - who is going to > > collect all patches and make one whole form them. As long as each of us > > works on a different thing - this should not be a big problem, but still - > > needs to be one person. > > As far as I'm concerned, there is no need to change anything. If someone > has patches for pgaccess, send them to -patches and they will be applied. > When a new release of PostgreSQL happens, a new pgaccess will be > distributed. Simple enough. > > If and when patches for pgaccess appear in significant numbers and for > some reason, which I cannot imagine, this procedure doesn't end up being > practical, we can consider the alternatives. But before you spend a lot > of time building a new infrastructure, let's see some code. All very practical, execpt for one point: the people being pulled togther for this _have_ code, with nowhere to put it: they've been developing new features for pgaccess, on top of the stable pgsql. Tracking CVS tip means that the current version of pgaccess there is either broken by underlying pgsql changes (I think that is currently true with Tom's schema work) or does not work with the current stable version og pgsql. While it would be nice to have one pgaccess that can work with any pgsql backend, that's not currently the case. One solution would be to work on the release branch, but that's discouraged - bug fixes only. Ross
...
> While it would be nice to have one pgaccess that can work with any pgsql
> backend, that's not currently the case. One solution would be to work
> on the release branch, but that's discouraged - bug fixes only.
Actually, CVS can support this just fine (I'll mention how below) but
afaict the discussion is moot because Iavor has declared that his group
prefers to take another path for now.
- Thomas
The solution could be to make a branch off of the stable branch to
support the pgaccess work. When folks are ready to merge down and
develop for 7.3, then they can do that using the "-j" option, jumping
straight from their development branch down to the main trunk (hence
never corrupting the stable branch), and then develop from there.
> Actually, CVS can support this just fine (I'll mention how below) but > afaict the discussion is moot because Iavor has declared that his group > prefers to take another path for now. > > - Thomas It is not 'my' group! I just happened to ask somebody in my company to patch something and then I send the code to Teo. And Teo asked Chris, Bartus and myself to bring our patches together. And I though of making this public. The discussion, however, went far beyond my intention. If somebody feels like managing this - I am off. I do not intend to moderate the future of an open source project in such a heavy climate. Especialy of a project I am not the author, not even a contributor - I am a pure manager. If nobody feels like managing this - let's give it a little bit of life and move it a bit forwards - and then talk again. Nothing wrong can happen the next two weeks. Iavor
...
> If nobody feels like managing this - let's give it a little bit of life and
> move it a bit forwards - and then talk again.
Iavor, I meant to be helpful; I was trying to put a name on The New
Group of Enthusiastic Developers Who Are Interested In Advancing
Pgaccess and shortened it to "Iavor's group". :)
> Nothing wrong can happen the next two weeks.
Certainly true. As The Developers Who Are Always Interested In Advancing
PostgreSQL And Really Like Pgaccess, we have just been trying to be
helpful and to make TNGoEDWAIIAP feel welcome to take advantage of any
existing or new resources in postgresql.org which they might want. So,
please know that TDWAAIIAPARLP are happy to support anything that
TNGoEDWAIIAP might want to do.
Regards.
- Thomas
Thomas :)))
In Europe it is 1:40 a.m.
Wish you a good night :)
And thanks,
Iavor
--
TNGoEDWAIIAP
-----Original Message-----
From: lockhart@fourpalms.org [mailto:lockhart@fourpalms.org]
Sent: Saturday, May 11, 2002 1:32 AM
To: Iavor Raytchev
Cc: pgsql-hackers; Tom Lane; Stanislav Grozev; Ross J. Reedstrom; Nigel
J. Andrews; Marc G. Fournier; Constantin Teodorescu; Cmaj; Boyan
Filipov; Boyan Dzambazov; Bartus. L; Brett Schwarz
Subject: Re: [HACKERS] internal voting
...
> If nobody feels like managing this - let's give it a little bit of life
and
> move it a bit forwards - and then talk again.
Iavor, I meant to be helpful; I was trying to put a name on The New
Group of Enthusiastic Developers Who Are Interested In Advancing
Pgaccess and shortened it to "Iavor's group". :)
> Nothing wrong can happen the next two weeks.
Certainly true. As The Developers Who Are Always Interested In Advancing
PostgreSQL And Really Like Pgaccess, we have just been trying to be
helpful and to make TNGoEDWAIIAP feel welcome to take advantage of any
existing or new resources in postgresql.org which they might want. So,
please know that TDWAAIIAPARLP are happy to support anything that
TNGoEDWAIIAP might want to do.
Regards.
- Thomas
Ross J. Reedstrom writes: > All very practical, execpt for one point: the people being pulled togther > for this _have_ code, with nowhere to put it: they've been developing > new features for pgaccess, on top of the stable pgsql. Tracking CVS > tip means that the current version of pgaccess there is either broken > by underlying pgsql changes (I think that is currently true with Tom's > schema work) or does not work with the current stable version og pgsql. We went through a very similar situation with the JDBC driver a release ago. A number of people had developed fixes or features for the driver and no one was collecting them. We've got those people working on the 7.2 branch and everything worked out well. Yes, this meant that the features and fixes were not immediately available in the 7.1 branch. But the alternative of forking pgaccess now is that the available fixes and features will not be available in the 7.3 branch for quite a while. -- Peter Eisentraut peter_e@gmx.net
On 2002.05.11 14:15 Peter Eisentraut wrote: > Ross J. Reedstrom writes: > > > All very practical, execpt for one point: the people being pulled > togther > > for this _have_ code, with nowhere to put it: they've been > developing > > new features for pgaccess, on top of the stable pgsql. Tracking CVS > > tip means that the current version of pgaccess there is either > broken > > by underlying pgsql changes (I think that is currently true with > Tom's > > schema work) or does not work with the current stable version og > pgsql. > > We went through a very similar situation with the JDBC driver a > release > ago. A number of people had developed fixes or features for the > driver > and no one was collecting them. We've got those people working on the > 7.2 > branch and everything worked out well. Yes, this meant that the > features > and fixes were not immediately available in the 7.1 branch. But the > alternative of forking pgaccess now is that the available fixes and > features will not be available in the 7.3 branch for quite a while. > But we have fixes and patches for this (7.2) version, why we sould wait for the next version. I think, there is no connection (should not be) between the versions of the pgaccess and the versions of the pgsql. Pgaccess is a visual tool for pgsql, that can be developed freely without having anything to do with the pgsql developement. So I cannot understand why the majority of the oppinions says that pgaccess should stay in the shadow of the pgsql. Breaking this tight connection we can help pgaccess to develop as fast as it can, and we let free space for other projects to appear. For me the first thing is to make my daily job as good and fast as I can. And this is much easier with using the best tool for the particular problem. This is why I started to make patches to this project. Sorry but I can't wait for the next pgsql release to have this patches included in the package. > -- > Peter Eisentraut peter_e@gmx.net > >
On Sat, 11 May 2002, Tom Lane wrote: > Au contraire --- what the JDBC folk did (and still are doing) was to > make "unofficial" releases consisting of snapshots pulled from their > chunk of the CVS tree. There were people making use of the "7.2 branch" > of JDBC long before the 7.2 server went beta, let alone final. > > Now this worked only because the JDBC driver makes a point of working > with older server versions as well as current, so it was possible to > use the updated driver with 7.1 and even older servers. I don't know > whether pgaccess does or should have a similar policy, but if it does > then the same approach should work well for it. Ah, I'm just composing an email on this subject destined for the -interfaces list. > > The alternative of maintaining a separate CVS tree and a separate > release schedule would really force exactly that policy on pgaccess > anyway --- if your releases aren't tied to the server's then you can > hardly expect to be sure which server version people will try to use > your code with. > > On the other hand, if the pgaccess developers would rather maintain > separate pgaccess versions for each server version, I see no reason > why they couldn't do that in the context of our CVS. They could work > in the REL7_2 branch for now (and make releases from it) then merge > forward to HEAD when they want to start thinking about 7.3 issues. > Or double-patch if they want to work on both versions concurrently. Really, I'd like interested parties to have look at waht I'm posting to -interfaces so they can shoot down my ideas on this. -- Nigel J. Andrews Director --- Logictree Systems Limited Computer Consultants
Peter Eisentraut <peter_e@gmx.net> writes:
> We went through a very similar situation with the JDBC driver a release
> ago. A number of people had developed fixes or features for the driver
> and no one was collecting them. We've got those people working on the 7.2
> branch and everything worked out well. Yes, this meant that the features
> and fixes were not immediately available in the 7.1 branch.
Au contraire --- what the JDBC folk did (and still are doing) was to
make "unofficial" releases consisting of snapshots pulled from their
chunk of the CVS tree. There were people making use of the "7.2 branch"
of JDBC long before the 7.2 server went beta, let alone final.
Now this worked only because the JDBC driver makes a point of working
with older server versions as well as current, so it was possible to
use the updated driver with 7.1 and even older servers. I don't know
whether pgaccess does or should have a similar policy, but if it does
then the same approach should work well for it.
The alternative of maintaining a separate CVS tree and a separate
release schedule would really force exactly that policy on pgaccess
anyway --- if your releases aren't tied to the server's then you can
hardly expect to be sure which server version people will try to use
your code with.
On the other hand, if the pgaccess developers would rather maintain
separate pgaccess versions for each server version, I see no reason
why they couldn't do that in the context of our CVS. They could work
in the REL7_2 branch for now (and make releases from it) then merge
forward to HEAD when they want to start thinking about 7.3 issues.
Or double-patch if they want to work on both versions concurrently.
regards, tom lane
Iavor Raytchev wrote: > > > If and when patches for pgaccess appear in significant numbers and for > > some reason, which I cannot imagine, this procedure doesn't end up being > > practical, we can consider the alternatives. But before you spend a lot > > of time building a new infrastructure, let's see some code. > > > > -- > > Peter Eisentraut peter_e@gmx.net > > We are working on it, because we have some code. > > Don't you believe us, or do you think we have a lot of free time to waste? > > We - Chris, Bartus, Boyan and myself, have enough patches we want to merge. > And we do not feel like asking for permisson to do it. We sent them to Teo > and we were asked by Teo to meet and see what we can do with our patches. > And we were nice enough to tell the world about this. > > I do not feel neither like 'asking for permisson', nor like 'proving' > anything. If somebody wants to help - is welcome. I find that this group is frustrating to work with. They seem very intolerant of the plurality. I did a configuration patch several months ago. I liked it, as did some others. It did not affect any existing behavior, but added the ability to store configuration information in a different location than the data, and share files between multiple PostgreSQL instances. Rather than evaluate the patch, and say it needs these changes, or simply applying it, you know, working with the contributor's to make a better project, they ranted and raved how they didn't like it, how they wanted something better, etc. No good technical reasons were given, mind you, just "I don't like this." So, I did the work, for what? Nothing. It is pointless for me to make the changes for each release. Fortunately it wasn't too much work. So, my experience tells me that unless the work you do is something they want, you are wasting your time. If you try to get some feedback from them about an approach you wish to take, so you don't waste your time, they flame you and tell you to put up or shut up. If you intend to undertake a major work on PostgreSQL, it had better be for something other than contribution back to the group, otherwise, there is a good possibility that you are going to waste your time. I do not get paid to work on PostgreSQL, the time I spend on it is either my own or for a project I am working on. I am finding it very unsatisfying.
On Mon, 13 May 2002, mlw wrote: > Iavor Raytchev wrote: > > > > > If and when patches for pgaccess appear in significant numbers and for > > > some reason, which I cannot imagine, this procedure doesn't end up being > > > practical, we can consider the alternatives. But before you spend a lot > > > of time building a new infrastructure, let's see some code. > > > > > > -- > > > Peter Eisentraut peter_e@gmx.net > > > > We are working on it, because we have some code. > > > > Don't you believe us, or do you think we have a lot of free time to waste? > > > > We - Chris, Bartus, Boyan and myself, have enough patches we want to merge. > > And we do not feel like asking for permisson to do it. We sent them to Teo > > and we were asked by Teo to meet and see what we can do with our patches. > > And we were nice enough to tell the world about this. > > > > I do not feel neither like 'asking for permisson', nor like 'proving' > > anything. If somebody wants to help - is welcome. > > I find that this group is frustrating to work with. They seem very intolerant > of the plurality. > > I did a configuration patch several months ago. I liked it, as did some others. > It did not affect any existing behavior, but added the ability to store > configuration information in a different location than the data, and share > files between multiple PostgreSQL instances. > > Rather than evaluate the patch, and say it needs these changes, or simply > applying it, you know, working with the contributor's to make a better project, > they ranted and raved how they didn't like it, how they wanted something > better, etc. No good technical reasons were given, mind you, just "I don't like > this." > > So, I did the work, for what? Nothing. It is pointless for me to make the > changes for each release. Fortunately it wasn't too much work. So, my > experience tells me that unless the work you do is something they want, you are > wasting your time. If you try to get some feedback from them about an approach > you wish to take, so you don't waste your time, they flame you and tell you to > put up or shut up. > > If you intend to undertake a major work on PostgreSQL, it had better be for > something other than contribution back to the group, otherwise, there is a good > possibility that you are going to waste your time. > > I do not get paid to work on PostgreSQL, the time I spend on it is either my > own or for a project I am working on. I am finding it very unsatisfying. This is the unfortunate impression I'm getting from some people on the HACKERS list, which is why discussion has moved temporarily to INTERFACES until pgaccess.org has its own mailing list. Plus that and the fact that pgaccess is an interface to postgresql. Also, INTERFACES seems to be a lot more newbie questions but these people are trying to learn so it is a more welcoming environment. What is strange is that you weren't even talking about a fork, which seems to be the central philosophical issue with pgaccess at the moment. All I can say to reassure people is that it is still _PG_access, not _access_ *ick*. --Chris -- cmaj_at_freedomcorpse_dot_info fingerprint 5EB8 2035 F07B 3B09 5A31 7C09 196F 4126 C005 1F6A
Discontent with development process (was:Re: pgaccess - the discussion is over)
From
Lamar Owen
Date:
[trimmed cc list, but left on HACKERS due to the nature of the subject (which was changed] On Monday 13 May 2002 10:56 am, mlw wrote: > Iavor Raytchev wrote: > > Peter Eisentraut wrote: > > > let's see some code. > > I do not feel neither like 'asking for permisson', nor like 'proving' > > anything. If somebody wants to help - is welcome. > I find that this group is frustrating to work with. They seem very > intolerant of the plurality. > I did a configuration patch several months ago. I liked it, as did some > others. It did not affect any existing behavior, but added the ability to > store configuration information in a different location than the data, and > share files between multiple PostgreSQL instances. While I personally felt that your patch was useful, there were other concerns. > Rather than evaluate the patch, and say it needs these changes, or simply > applying it, you know, working with the contributor's to make a better > project, they ranted and raved how they didn't like it, how they wanted > something better, etc. No good technical reasons were given, mind you, just > "I don't like this." I think you might want to reread that thread. There _were_ in fact technical aspects of the situation -- primarily due to the _plurality_ of the development process around here. It isn't 'plural' to have someone announce that they have a patch, and then it gets applied without the discussion of the established developers. No -- changes to this codebase are done by a plurality -- meaning the entire pgsql-hackers group. (Well, at least that's how it's supposed to be -- it doesn't always work that way.....). Your patch was discussed -- the resolution seemed to me to be in favor of including that functionality in 7.3. To which I was very happy. This isn't the Linux kernel with a benevolent dictator who can unilaterally apply patches -- this is an oligarchy with the six core developers, together with the rest of us, making those decisions as a group. The discussions aren't flames -- at least I didn't take any of those discussions to be flames. While there are a few opinionated ones here (myself included), we do tend to take things on technical merit. Had you patch merited inclusion without discussion -- well, that wouldn't have happened, regardless of its merits -- we were in beta, IIRC. IIRI, then I apologize. In beta new features are frowned upon -- and your patch introduced a substantial new feature, one that needed careful thought before implemention. While your patch works for you, as written it didn't necessarily work for everyone. BTW, it would have worked great for me and my purposes, but PostgreSQL isn't a vehicle for my personal purposes. The discussion I remember was a little antsy primarily due to the fact that we were in beta. Then was not the time; now is. Reintroduce the topic now, and let's see what happens. > I do not get paid to work on PostgreSQL, the time I spend on it is either > my own or for a project I am working on. I am finding it very unsatisfying. I do not currently get paid for working on it either. Do I find it satisfying? Most of the time I do. But if you don't find it satisfying, well, there could be more than one reason. But the biggest problem I see was the inappropriate timing of the patch. Again, _NOW_ would be a good time to reintroduce the topic, as we're not in beta, and all of the developers are much more likely to be open to these ideas. But go back to the previous thread in the archives and see where we left off first, so that everybody starts on the same page of music. But understand that those who don't need the functionality are likely not not be thrilled by changes to a currently stable codebase. Although this config file stuff is small potatoes compared to the Win32 stuff as recently discussed. And for that, please understand that most of the developers here consider Win32 an inferior server platform. In fact, Win32 _is_ an inferior server platform, at least in my opinion. But, if you want to do the work, and it doesn't break my non-Win32 server build, by all means go for it. With that said, I hope you'll consider sticking it out and seeing it through at least two major cycles. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Re: Discontent with development process (was:Re: pgaccess - the discussion is over)
From
Tom Lane
Date:
Lamar Owen <lamar.owen@wgcr.org> writes:
> Although this config file stuff is small potatoes compared to the
> Win32 stuff as recently discussed. And for that, please understand
> that most of the developers here consider Win32 an inferior server
> platform. In fact, Win32 _is_ an inferior server platform, at least
> in my opinion. But, if you want to do the work, and it doesn't break
> my non-Win32 server build, by all means go for it.
Note that "doesn't break non-Win32 builds" is not really the standard
that will get applied. Ongoing readability and maintainability of the
codebase is a very high priority in my eyes, and I think in the eyes
of most of the key developers. To the extent that Win32 support can
be added without hurting those goals, I have nothing against it.
I'll even put up with localized ugliness (see the BeOS support hacks
for an example of what I'd call localized ugliness). But I get unhappy
when there's airy handwaving about moving all static variables into some
global data structure, to take just one of the points that were under
discussion last week. That'd be a big maintainability penalty IMHO.
As for the more general point --- my recollection of that thread was
that mlw himself was more than a bit guilty of adopting a "my way or no
way" attitude; if he sees some pushback from the other developers maybe
he should consider the possibility that he's creating his own problem.
In general this development community is one of the most civilized I've
ever seen. I don't think it's that hard to get consensus on most
topics. The consensus isn't always the same as my personal opinion...
but that's the price of being part of a community.
regards, tom lane
On Mon, 13 May 2002, Lamar Owen wrote: > But understand that those who don't need the functionality are likely not not > be thrilled by changes to a currently stable codebase. Although this config > file stuff is small potatoes compared to the Win32 stuff as recently > discussed. And for that, please understand that most of the developers here > consider Win32 an inferior server platform. In fact, Win32 _is_ an inferior > server platform, at least in my opinion. But, if you want to do the work, > and it doesn't break my non-Win32 server build, by all means go for it. Actually, even for those that wuldn't need the patch ... as long as the "default behaviour" doesn't change, and unless there are no valid technical arguments around it, there is no reason why a patch shouldn't be included ...
> Actually, even for those that wuldn't need the patch ... as long as the > "default behaviour" doesn't change, and unless there are no valid > technical arguments around it, there is no reason why a patch shouldn't be > included ... Unless it's going to interfere with implementing the general case in the future, making it a painful feature to keep backwards-compatibility with. Which is what the discussion was about IIRC... Chris
On Tue, 2002-05-14 at 04:03, Tom Lane wrote: > Lamar Owen <lamar.owen@wgcr.org> writes: > > Although this config file stuff is small potatoes compared to the > > Win32 stuff as recently discussed. And for that, please understand > > that most of the developers here consider Win32 an inferior server > > platform. In fact, Win32 _is_ an inferior server platform, at least > > in my opinion. But, if you want to do the work, and it doesn't break > > my non-Win32 server build, by all means go for it. > > Note that "doesn't break non-Win32 builds" is not really the standard > that will get applied. Ongoing readability and maintainability of the > codebase is a very high priority in my eyes, and I think in the eyes > of most of the key developers. To the extent that Win32 support can > be added without hurting those goals, I have nothing against it. > I'll even put up with localized ugliness (see the BeOS support hacks > for an example of what I'd call localized ugliness). But I get unhappy > when there's airy handwaving about moving all static variables into some > global data structure, What would your opinion be of some hack with macros, like #if (Win32 or THREADED) #define GLOBAL_ pg_globals. #else #define GLOBAL_ #endif and then use global variables as GLOBAL_globvar At least in my opinion that would increase both readability and maintainability. > to take just one of the points that were under > discussion last week. That'd be a big maintainability penalty IMHO. ----------------- Hannu
Re: Discontent with development process (was:Re: pgaccess - the discussion is over)
From
Tom Lane
Date:
Hannu Krosing <hannu@tm.ee> writes:
> What would your opinion be of some hack with macros, like
> #if (Win32 or THREADED)
> #define GLOBAL_ pg_globals.
> #else
> #define GLOBAL_
> #endif
> and then use global variables as
> GLOBAL_globvar
> At least in my opinion that would increase both readability and
> maintainability.
From a code readability viewpoint this is not at all better than just
moving everything to pg_globals. You're only spelling "pg_globals."
a little differently. And it introduces twin possibilities for error:
omitting GLOBAL_ (if you're a Unix developer) or writing
pg_globals. explicitly (if you're a Win32 guy). I suppose these errors
would be caught as soon as someone tried to compile on the other
platform, but it still seems like a mess with little redeeming value.
I think there had been some talk of
#if Win32
#define myvar pg_globals.f_myvar
#else
static int myvar;
#endif
which seems a more effective use of macros --- it would at least allow
the code to be written without explicit awareness of the special status
of the variable. Still seems like a maintenance nightmare though.
The real problem with airily saying "we'll just move that variable to
pg_globals" is that it falls down the instant that you consider
non-scalar variables. What if it's a pointer to a palloc'd structure?
Sure we can get around this, but not transparently.
regards, tom lane
Tom Lane wrote: > Lamar Owen <lamar.owen@wgcr.org> writes: > > Although this config file stuff is small potatoes compared to the > > Win32 stuff as recently discussed. And for that, please understand > > that most of the developers here consider Win32 an inferior server > > platform. In fact, Win32 _is_ an inferior server platform, at least > > in my opinion. But, if you want to do the work, and it doesn't break > > my non-Win32 server build, by all means go for it. > > Note that "doesn't break non-Win32 builds" is not really the standard > that will get applied. Ongoing readability and maintainability of the > codebase is a very high priority in my eyes, and I think in the eyes > of most of the key developers. To the extent that Win32 support can > be added without hurting those goals, I have nothing against it. The tricky twist will be to keep good readability while taking different solution approaches for different Systems (e.g. fork() only for *NIX vs. CreateProcess() for Win). I agree that your high priority goal is a good one. Thinking about good old Unix semantics, having a higher priority means not beeing as nice as others, right? Then again, even with the lowest possible nice level a process doesn't own the CPU exclusively (so it never becomesrude). > I'll even put up with localized ugliness (see the BeOS support hacks > for an example of what I'd call localized ugliness). But I get unhappy > when there's airy handwaving about moving all static variables into some > global data structure, to take just one of the points that were under > discussion last week. That'd be a big maintainability penalty IMHO. As I understood it the idea was to put the stuff, the backends inherit from the postmaster, into a centralized place, instead of having it spread out all over the place. What's wrong with that? > As for the more general point --- my recollection of that thread was > that mlw himself was more than a bit guilty of adopting a "my way or no > way" attitude; if he sees some pushback from the other developers maybe > he should consider the possibility that he's creating his own problem. > In general this development community is one of the most civilized I've > ever seen. I don't think it's that hard to get consensus on most > topics. The consensus isn't always the same as my personal opinion... > but that's the price of being part of a community. Yeah, maybe democracy wasn't such a perfect idea at all ... Jan ;-) -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== JanWieck@Yahoo.com #
Re: Discontent with development process (was:Re: pgaccess - the discussion is over)
From
Tom Lane
Date:
Jan Wieck <janwieck@yahoo.com> writes:
> As I understood it the idea was to put the stuff, the
> backends inherit from the postmaster, into a centralized
> place, instead of having it spread out all over the place.
> What's wrong with that?
The main objection to it in my mind is that what had been private
variables in specific modules now become exceedingly public. Instead of
looking at "static int foo" and *knowing* that all the references are in
the current file, you have to go trolling the entire backend to see who
is referencing pg_globals.foo.
I have not counted to see how many variables are really affected; if
there's only a few then it doesn't matter much. But the people who
have done this so far have all reported inserting tons of #ifdefs,
which leads me to the assumption that there's a lot of 'em.
regards, tom lane
Re: Discontent with development process (was:Re: pgaccess - the discussion is over)
From
Myron Scott
Date:
Tom Lane wrote: >Hannu Krosing <hannu@tm.ee> writes: > >>What would your opinion be of some hack with macros, like >> > >>#if (Win32 or THREADED) >>#define GLOBAL_ pg_globals. >>#else >>#define GLOBAL_ >>#endif >> > >>and then use global variables as >> > >>GLOBAL_globvar >> > >>At least in my opinion that would increase both readability and >>maintainability. >> > >>From a code readability viewpoint this is not at all better than just >moving everything to pg_globals. You're only spelling "pg_globals." >a little differently. And it introduces twin possibilities for error: >omitting GLOBAL_ (if you're a Unix developer) or writing >pg_globals. explicitly (if you're a Win32 guy). I suppose these errors >would be caught as soon as someone tried to compile on the other >platform, but it still seems like a mess with little redeeming value. > Another suggestion might be to create a global hashtable that stores the size and pointer to global structures for each subsection. Each subsection can define its own globals structure and register them with the hashtable. This would not impact readablity and make the gobal environment easy to copy. IMHO, this is possible with minimal performance impact. Myron Scott mkscott@sacadia.com
Re: Discontent with development process (was:Re: pgaccess - the discussion is over)
From
Tom Lane
Date:
Myron Scott <mkscott@sacadia.com> writes:
> Another suggestion might be to create a global hashtable that stores
> the size and pointer to global structures for each subsection. Each
> subsection can define its own globals structure and register them with
> the hashtable.
Hmm ... now *that* is an interesting idea.
With a little more intelligence in the manager of this table, this could
also solve my concern about pointer variables. Perhaps the entries
could include not just address/size but some type information. If the
manager knows "this variable is a pointer to a palloc'd string" then it
could do the Right Thing during fork. Not sure offhand what the
categories would need to be, but we could derive those if anyone has
cataloged the variables that get passed down from postmaster to children.
I don't think it needs to be a hashtable --- you wouldn't ever be doing
lookups in it, would you? Just a simple list of things-to-copy ought to
do fine.
regards, tom lane
Re: Discontent with development process (was:Re: pgaccess - the discussion is over)
From
Myron Scott
Date:
Tom Lane wrote: > > >With a little more intelligence in the manager of this table, this could >also solve my concern about pointer variables. Perhaps the entries >could include not just address/size but some type information. If the >manager knows "this variable is a pointer to a palloc'd string" then it >could do the Right Thing during fork. Not sure offhand what the >categories would need to be, but we could derive those if anyone has >cataloged the variables that get passed down from postmaster to children. > >I don't think it needs to be a hashtable --- you wouldn't ever be doing >lookups in it, would you? Just a simple list of things-to-copy ought to >do fine. > > I'm thinking in a threaded context where a method may need to lookup a global that is not passed in. But for copying, I suppose no lookups would be neccessary. Myron Scott mkscott@sacadia.com
Global Variables (Was: Re: Discontent with development process (was:Re: pgaccess - the discussion is over) )
From
"Marc G. Fournier"
Date:
Mark (mlw) ... could you generate a listing of those variables you feel would need to be moved to a 'global structure' and post that to the list? That would at least give us a starting point, instead of both sides guessing at what is/would be involved ... On Tue, 14 May 2002, Tom Lane wrote: > Jan Wieck <janwieck@yahoo.com> writes: > > As I understood it the idea was to put the stuff, the > > backends inherit from the postmaster, into a centralized > > place, instead of having it spread out all over the place. > > What's wrong with that? > > The main objection to it in my mind is that what had been private > variables in specific modules now become exceedingly public. Instead of > looking at "static int foo" and *knowing* that all the references are in > the current file, you have to go trolling the entire backend to see who > is referencing pg_globals.foo. > > I have not counted to see how many variables are really affected; if > there's only a few then it doesn't matter much. But the people who > have done this so far have all reported inserting tons of #ifdefs, > which leads me to the assumption that there's a lot of 'em. > > regards, tom lane > > ---------------------------(end of broadcast)--------------------------- > TIP 5: Have you checked our extensive FAQ? > > http://www.postgresql.org/users-lounge/docs/faq.html >
On Tue, 14 May 2002, Myron Scott wrote: > > > Tom Lane wrote: > > > > > > >With a little more intelligence in the manager of this table, this could > >also solve my concern about pointer variables. Perhaps the entries > >could include not just address/size but some type information. If the > >manager knows "this variable is a pointer to a palloc'd string" then it > >could do the Right Thing during fork. Not sure offhand what the > >categories would need to be, but we could derive those if anyone has > >cataloged the variables that get passed down from postmaster to children. > > > >I don't think it needs to be a hashtable --- you wouldn't ever be doing > >lookups in it, would you? Just a simple list of things-to-copy ought to > >do fine. > > > > > I'm thinking in a threaded context where a method may need to lookup a > global that is not passed in. But for copying, I suppose no lookups > would be neccessary. if we can, can we keep the whole 'threaded' concept in mind when developing this ... if going a hashtable would be required for this, let's go the more complete route and eliminate potential issues down the road ...
"Marc G. Fournier" wrote:
>
> Mark (mlw) ... could you generate a listing of those variables you feel
> would need to be moved to a 'global structure' and post that to the list?
> That would at least give us a starting point, instead of both sides
> guessing at what is/would be involved ...
(1) All the configuration info.
(2) All the globals in postmaster.c
(3) Make sure that memory contexts are initialized correctly.
(4) Exception handling.
(5) Make sure that the statistics and other child processes work too.
In BackendStartup(), rather than "pid = fork();" You should split the routine
at that point, one end will be called for error and successful exec of child
process, another will be called for the child.
On UNIX, it will merely be a slight rearrangement of the code. On Windows it
will represent a different function which will copy the globals from the
parent, and call in. Think of it like this:
Currently it looks something like this:
BackendStartup(port)
{....pid = fork();
if( pid < 0) // errorelse if(pid ) // Still in Parentelse // Do child
}
This would have to change to this:
BackendStartup(port)
{...
pid = StartBackendProcess(port);
if(pid < 0) // Errorelse if(pid) // Still in Parentelse exit(DoBackend()); // Will never happen on Windows.
}
#ifdef WIN32
StartBackendProcess(port)
{HANDLE hprocess= CreateProcess("...../postgres", ....);
(initialize process here)return hprocess;
}
#endif
#ifdef HAS_FORK
StartBackendProcess(port)
{return fork();
}
#endif
In the main code (src/backend/main), you would have to pass a parameter to the
backend to inform it that is being started as a child of the postmaster, and to
call DoBackend() under windows. MPI does this sort of thing.
I see the whole thing as fairly straight forward. Fork is nothing more than a
copy. We should be able to identify what postmaster does prior to the fork of a
backend. The tricks are to handle the shared memory and semaphores, but those
are easy too. We could create a DLL for Postgres which has implicitly shared
data amongst the processes, and make sure that Postmaster updates all the
shared data prior to entering its server loop. That way the backends are only
reading data from a shared resource.
Once the Windows version of PostgreSQL is able to exec the child, I think the
areas where there are things that were missed should be pretty obvious.
It should take a pretty good engineer a few (full time, 40+ hours) weeks. It
should be mostly done the first week, the last two weeks would be chasing bugs
created by variables that were not initialized. This assumes, of course, that
you are using a cygwin build environment without the cygwin or cygipc dlls. If
we were to use MS C/C++ it would take a much longer time, although ultimately
that may be the desired direction.
P.S.
I have unsubscribed from the hackers list, if you wish to contact me, use my
email address directly.