possible to create CVS branch for proposed patch?

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, Pennsylvania 19026

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/