Thread: possible to create CVS branch for proposed patch?
Jason Tishler and I are planning to create a patch to allow PostgreSQL to run directly as an NT service. I've submitted a similar patch which may well be incorporated into the next release of Cygipc, and we've got a plan for doing the same for PostgreSQL: see http://ontosys.com/phiki/PostgresqlNtServiceDesign I've vetted that plan past this group and have incorporated feedback. Getting to my question: Is it possible to create a CVS branch of the HEAD (tip) of the PostgreSQL CVS for us to use in this work? Having such a branch would allow Jason and I to coordinate our work easily, and it also gives the pgsql-hackers community an easy way to view (and review) our work. Once/if the work is stable and approved, we/someone could then use CVS tools to merge that branch back onto the main line and cease any further work on that branch. -- Fred Yankowski fred@OntoSys.com tel: +1.630.879.1312 Principal Consultant www.OntoSys.com fax: +1.630.879.1370 OntoSys, Inc 38W242 Deerpath Rd, Batavia, IL 60510, USA
Fred Yankowski <fred@ontosys.com> writes:
> Getting to my question: Is it possible to create a CVS branch of the
> HEAD (tip) of the PostgreSQL CVS for us to use in this work?
It seems unlikely that this work is large enough to justify a branch.
Why don't you just work together and submit a patch when you are done?
We have talked about using branches for projects of the scale of the
planned querytree redesign, which would (a) hit most of the backend,
and (b) break everything until it's done, so other developers couldn't
get anything done meanwhile if it's done on the tip. An NT-service
wrapper should not have either of those properties, seems to me.
regards, tom lane
Fred Yankowski writes: > Jason Tishler and I are planning to create a patch to allow PostgreSQL > to run directly as an NT service. I've submitted a similar patch > which may well be incorporated into the next release of Cygipc, and > we've got a plan for doing the same for PostgreSQL: see > http://ontosys.com/phiki/PostgresqlNtServiceDesign > I've vetted that plan past this group and have incorporated feedback. Seems like something that should be done in a separate wrapper program. Littering the backend with vast sections of platform-specific code that provides optional functional is probably not going to fly, if I can assess this group correctly. -- Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
On Wed, Feb 14, 2001 at 07:43:25PM +0100, Peter Eisentraut wrote: > Seems like something that should be done in a separate wrapper program. > Littering the backend with vast sections of platform-specific code that > provides optional functional is probably not going to fly, if I can assess > this group correctly. Our plan puts most of the work in a new NT/Cygwin-only version of backend/main.c. If we can use the existing signal() scheme to shut down PG, then we might not have to touch _anything_ else. What do you see in our plan that implies "vast sections of platform-specific code" "littering the backend"? If such changes are necessary, I want to know before we embark on this work. As far as this being "optional functional[ity]", I contend that PostgreSQL has no place as a ready-for-business tool on NT without this (or similar) work so that PG runs cleanly as a service, starting up and shutting down properly. -- Fred Yankowski fred@OntoSys.com tel: +1.630.879.1312 Principal Consultant www.OntoSys.com fax: +1.630.879.1370 OntoSys, Inc 38W242 Deerpath Rd, Batavia, IL 60510, USA
> On Wed, Feb 14, 2001 at 07:43:25PM +0100, Peter Eisentraut wrote: > > Seems like something that should be done in a separate wrapper program. > > Littering the backend with vast sections of platform-specific code that > > provides optional functional is probably not going to fly, if I can assess > > this group correctly. > > Our plan puts most of the work in a new NT/Cygwin-only version of > backend/main.c. If we can use the existing signal() scheme to shut > down PG, then we might not have to touch _anything_ else. > > What do you see in our plan that implies "vast sections of > platform-specific code" "littering the backend"? If such changes are > necessary, I want to know before we embark on this work. > > As far as this being "optional functional[ity]", I contend that > PostgreSQL has no place as a ready-for-business tool on NT without > this (or similar) work so that PG runs cleanly as a service, starting > up and shutting down properly. Agreed. We just want to minimize the affect on other areas of the code. We have been pretty good at keeping platform-specific stuff isolated. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
Fred Yankowski writes: > What do you see in our plan that implies "vast sections of > platform-specific code" "littering the backend"? If such changes are > necessary, I want to know before we embark on this work. > > As far as this being "optional functional[ity]", I contend that > PostgreSQL has no place as a ready-for-business tool on NT without > this (or similar) work so that PG runs cleanly as a service, starting > up and shutting down properly. Having one program do different things on different platforms is something that should be avoided at all costs, IMHO. Every platform has its, varyingly complex, requirements for starting daemons at boot time, but still the backend is isolated from these considerations. For that we have pg_ctl, contrib/start-scripts, or other solutions. Before I see specific code I can't comment on your issue, but it's hard to imagine that a wrapper program couldn't cover it. -- Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/