I did get the bash command to work: ps -asW
It basically gave me what Task Manager process list gave me AFAICS

I monitored Task Manager while running the make check from the bash shell (this confirms in real time whether I'm looking at the relevant processes during the regression test) - the postgres processes definitely use either my workstation sign-on UID (= my LAN ID) when I run without the runas option, or they are owned by 'postgres' when I run the bash with the runas option for 'postgres'...

my LAN result for trying to start postmaster = timeout
'postgres' result for trying to start postmaster = access denied

Also, I notice the McShield process is checking all the files when it creates the temp install for the regression test... I wonder if it's affecting access to the postmaster with the 'postgres' id ??

And perhaps the binary version somehow circumvents McShield with respect to postmaster, allowing it to run... just a wild guess

I sorry to hear that your having a hard time getting the temporal extension built with a windows version of PostgreSQL. (IMG:style_emoticons/default/frown.gif) As a side note, I know that Jeff Davis the author of the temporal extension was given approval on a more generic data-type referred to as "range types" for 9.1 *in core*. The temporal data-type simply be one application of this concept. On the plus side you'll be able to build ranges for *most* any data-types such as int, date, time-stamp and others.

But this doesn't help you at the moment and Jeff hasn't released a patch yet, so we can't even test it in an alpha version yet.

Now regarding your problem at hand, If you are successful in finding a way to get the temporal extension working for the windows version of PostgreSQL I'd be happy to hear *how* you achieved it. In fact I'd like to make a wiki out of your experience.

Having stated this, I need to offer a sanity check. At some point, if you really want to use the temporal data type, you have to ask yourself if the effort of getting the temporal extension to work on windows is more difficult than getting a linux/bsd installation at your place of employment. This is just a thought to keep in mind.

I'm personally awaiting the alpha version of 9.1 where the range-types are applied for testing.

Here is the status of the current patch proposal.
http://wiki.postgresql.org/wiki/RangeTypes

Here is another project that added temporal capability to postgresql (and oracle):
http://scottrbailey.wordpress.com/2009/10/06/timespan_sets/
http://sourceforge.net/projects/chronosdb/

Wow, those range data types really sound like a great expansion on the temporal concept and period data type. Especially if they get into *core* for 9.1 (IMG:style_emoticons/default/cool.gif)

Those other links for the ChronosDb package are also great. The reference material you've provided thus far has been very helpful (IMG:style_emoticons/default/thanks.gif)

I found some confirming evidence that anti-virus software will throw a wrench into a Windows install, and they even mention that regression tests are the place where the process gets hung up, as well as mentioning McAfee as being a culprit AV software package, which of course is running on my machine:
pg install for Windows

Anyways, on the sanity front, my colleague may be able to snag a spare computer and either a) try an XP install without the AV hindrance, or b) install on a Linux platform

I'll be sure to report any successes, and I'd be perfectly willing to share the particulars of getting the darn thing to install from source on XP. It's been a learning curve for sure!

Cheers,
John

Why bother installing XP? Linux seems to me the path of least resistance, but that's just me. One additional benefit is that you can also choose a small footprint Linux which also means you can dedicate more of the computer's horsepower to PostgreSQL without paying for all fancy doodads that you wouldn't be using - you'd be managing the server remotely anyway and the surface area for attack also becomes much smaller because you can be sure to turn on only services you need for PostgreSQL to function. Contrast with Windows XP's propensity to "helpfully" turn on service in name of convenience. (IMG:style_emoticons/default/blush.gif)

Either way, I'd love to hear how it turns out.

After all this rigmarole, I definitely hear you - why keep fussing with XP?
I guess for one, it's all we've got right now to work with. It's your standard corporate workstation environment and XP is what they give us.
If we manage to track down a spare computer, then Linux definitely becomes a possibility, or "the" goto.

Our initial purpose with postgres is not overly ambitious in terms of storage, concurrent users, or any other sort of resource allocation, security issue or performance aspect, so I'm not overly concerned with the host machine/OS. That said, it's really become apparent how postgres and Windows have not so much love for each other, or rather, how much of a problem child Windows can be (IMG:style_emoticons/default/crazy.gif)

Having gotten this far, it's hard to let go of getting the Windows build to work - but fortunately, we're not under much pressure to "get going" with postgres - it's more of a personal interest project at the moment.

Richard, my hat is off to you -
Your link to the Scott Bailey ChronosDB temporal patch was the ticket!
I managed to install it on XP for the binary version of pg 9.0 (a much easier task than wrestling with source)

It gives me the period data type (Scott's own composite version) plus a host of functions for it. So it looks like I'm off to the races! (IMG:style_emoticons/default/thumbup.gif)

Tremendous thanks to you and Banana for sticking with me through all this and getting me to the 'pg promised land' (IMG:style_emoticons/default/notworthy.gif)

Best,
John

Congratulations. I'm happy to hear that you made a success of it. Now that you have a temporally aware database, here are a few ideas that you might like:

1) Temporal DB design
2) Temporal Transaction logging

To use a class room illustration for 1) you can now guarantee temporal uniqueness for any class room and teacher. So, a class room cannot be double booked by two teachers at the same time. And a teacher cannot be booked to teach in two class rooms at the same time. Also you can find the ranges of time when the teacher or class room are not scheduled.

For 2) you can place triggers that push any changes a user makes out to a history table. With this history, you can support drop-down undo lists (Oops i accidentally changed this field. what was its value before my mistake? Or "why did 'disgruntled_employee_id' delete every record from this important table?").
You can allow custom drop-down list sortings (i.e. Instead of alphanumeric, you can get the most frequently chosen items (MFCI), the MFCI for this week, or the MFCI this day, ... ).


Anyway, these are some of the reasons, I like temporally aware databases.

Have fun! I'm sure that once you get the hang of it, you begin to imagine many other powerful uses for temporal data

I wanted to mentioned that PostgreSQL just published A Beta version of 9.2. It includes the new RANGE Types that can be used to develop Temporal Databases when combined with Btree_Gist index extension module.

http://www.postgresql.org/docs/devel/static/rangetypes.html
http://www.postgresql.org/docs/devel/static/btree-gist.html