internal voting

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...

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> 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

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

[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

On 2002.05.11 20:27 Nigel J. Andrews wrote:

[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.

Sure, there is a problem, that's why the whole discussion started. A
software project stalled for at least a year. Why? There is no need for
it? I can hardly beleive.

Sorry, but I cannot understand your last sentence. Could you explain to
me, please?

I don't want to hurt anybody's feelings, I just want to help this
software to be better, nothing more.

--
Nigel J. Andrews
Director

---
Logictree Systems Limited
Computer Consultants

Best regards,
Levi.

On Sat, 11 May 2002, Bartus Levente wrote:

On 2002.05.11 20:27 Nigel J. Andrews wrote:

On Sat, 11 May 2002, Bartus Levente wrote:

[snip]
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.

[snip]

Sorry, but I cannot understand your last sentence. Could you explain to
me, please?

All I mean is that if your patches are making major changes to the majority of
the files making up pgaccess and that the new CVS repository is going to be
initialised from a version that does not have your patches _and_ that this
initial version has been patched by others then there is possibly going to be a
lot of work to bring your patches into CVS. On the hand I suppose this could
just be viewed as the normal problem of merging patches so I'm inclined to not
worry. However, if people are working on pgaccess at the moment then
it is a good idea that their work is applied to pgaccess in the postgres tree
so everyone else can get their hands on it while we wait for the new CVS.

I am assuming here that there is a new CVS repository coming along for
pgaccess, that it will be initialised with the code from the postgres tree [and
that pgaccess in the postgres tree will be synchronised frequently].

I don't want to hurt anybody's feelings, I just want to help this
software to be better, nothing more.

Mine aren't hurt :)

--
Nigel J. Andrews
Director

---
Logictree Systems Limited
Computer Consultants

On 2002.05.11 23:57 Nigel J. Andrews wrote:

On Sat, 11 May 2002, Bartus Levente wrote:

On 2002.05.11 20:27 Nigel J. Andrews wrote:

On Sat, 11 May 2002, Bartus Levente wrote:

[snip]
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.

[snip]

Sorry, but I cannot understand your last sentence. Could you explain

to

me, please?

All I mean is that if your patches are making major changes to the
majority of
the files making up pgaccess and that the new CVS repository is going
to be
initialised from a version that does not have your patches _and_ that
this
initial version has been patched by others then there is possibly
going to be a
lot of work to bring your patches into CVS. On the hand I suppose this
could
just be viewed as the normal problem of merging patches so I'm
inclined to not
worry. However, if people are working on pgaccess at the moment then
it is a good idea that their work is applied to pgaccess in the
postgres tree
so everyone else can get their hands on it while we wait for the new
CVS.

We would like to merge our patches into the last release of the
pgaccess (apperently this is now in the postgres tree), and make this
for the future patches too.
So we set up pgaccess.org, with it's own cvs, mailing lists and
homepage. When Iavor searched for the last release almost a war started.

I am assuming here that there is a new CVS repository coming along for
pgaccess, that it will be initialised with the code from the postgres
tree [and
that pgaccess in the postgres tree will be synchronised frequently].

We would like to syncronise the postgres tree, and to give people a
place where they can find the software, tha latest release, can drop
wishes, and browse the to-do list easier. Is there any to-do list in
the postgres package regarding the pgaccess?

I don't want to hurt anybody's feelings, I just want to help this
software to be better, nothing more.

Mine aren't hurt :)

--
Nigel J. Andrews
Director

---
Logictree Systems Limited
Computer Consultants

Best regards,
Levi.

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

[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

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

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 becomes rude).

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 #

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

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

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

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

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:

"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)
// error
else if(pid )
// Still in Parent
else
// Do child
}

This would have to change to this:

BackendStartup(port)
{
...

pid = StartBackendProcess(port);

if(pid < 0)
// Error
else if(pid)
// Still in Parent
else
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.

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
...