NT port of PGSQL - success

Hi,

I have successeed in porting PostgreSQL to Win NT. The patch that is
included is for development version from Sep 15, but I think that the
changes are version independent. The main difference from other port is
the renamed system table pg_version (vs. PG_VERSION) to pg_ver - Windows

I thought Windows allowed any case, so you could open a file with
"PG_VERSION" or "pg_version" and it will open any file of any matching
case.

file names are case insensitive :-) So this should be solved on a global
level perhaps in main sources. And also the communication through
AF_UNIX sockets is disabled. There are only two other changes:
- added some flag while opening directory with open() syscall
- changed flags for file descriptor in function pq_init()
and that's all :-)

the steps ;-) are:
do the steps that Joost wrote some time ago
patch <pgsql.diff (maybe by hand for newer versions of PostgreSQL)
make
make install
initdb
postmaster -i

I was able to run postmaster and two concurrent psql connections
yesterday. I will run the test later.

This is amazing. You can actually run SQL statements on NT.

What would you like done with this patch? Should it merged into the
tree, or just used for people testing things on NT, and later merged in
as you feel more comfortable? You can make a 6.4 final patch, perhaps.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@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

changes are version independent. The main difference from

other port is

the renamed system table pg_version (vs. PG_VERSION) to

pg_ver - Windows

I thought Windows allowed any case, so you could open a file with
"PG_VERSION" or "pg_version" and it will open any file of any matching
case.

The problem is that there exists file PG_VERSION where is the current
version stored (now 6.4) in the directory ./data/base/template1 and when
the bootstrap code wants to create pg_version system table it stops
because the file with the "same" name already exists.

What would you like done with this patch? Should it merged into the
tree, or just used for people testing things on NT, and later
merged in
as you feel more comfortable? You can make a 6.4 final
patch, perhaps.

I think we should wait for the final 6.4 version (I hope it will be soon
available) and than make a patch against it and include it also in the
6.5 development tree. There are some open issues yet.

I run the regression tests yesterday, the results are here:
=============== running regression queries... =================
boolean .. ok
char .. ok
name .. ok
varchar .. ok
text .. ok
strings .. ok
int2 .. failed
int4 .. failed
int8 .. failed
oid .. ok
float4 .. ok
float8 .. failed
numerology .. failed
point .. ok
lseg .. ok
box .. ok
path .. ok
polygon .. ok
circle .. ok
geometry .. failed
timespan .. ok
datetime .. failed
reltime .. ok
abstime .. failed
tinterval .. failed
horology .. failed
comments .. ok
create_function_1 .. ok
create_type .. ok
create_table .. ok
create_function_2 .. failed
constraints .. failed
triggers .. failed
copy .. ok
create_misc .. ok
create_aggregate .. ok
create_operator .. ok
create_view .. ok
create_index .. ok
sanity_check .. ok
errors .. ok
select .. ok
select_into .. ok
select_distinct .. ok
select_distinct_on .. ok
select_implicit .. ok
select_having .. ok
subselect .. ok
union .. failed
aggregates .. ok
transactions .. ok
random .. ok
portals .. ok
misc .. failed
arrays .. ok
btree_index .. ok
hash_index .. ok
select_views .. ok
alter_table .. ok
portals_p2 .. ok
setup_ruletest .. ok
run_ruletest .. failed

now some explanations:
- int2, int4 - there are OK but there is a problem with the error
messages from libc
- int8 - the libc does probably have no support for long long ints in
printf()
- run_ruletest - the difference is only in the name that is selected
from the tables
- many other tests failed due to not having the dynamicly loaded code in
DLLs

Dan

The problem is that there exists file PG_VERSION where is the current
version stored (now 6.4) in the directory ./data/base/template1 and
when the bootstrap code wants to create pg_version system table it
stops because the file with the "same" name already exists.
I think we should wait for the final 6.4 version (I hope it will be
soon available) and than make a patch against it and include it also
in the 6.5 development tree.

Most of us aren't NT propellerheads, but now that a port might be
available I'm sure the mailing lists will get more folks who are. Then a
tremendous step forward such as you've take will be greeted with more
enthusiasm :)

There are some open issues yet.
now some explanations:
- int8 - the libc does probably have no support for long long ints in
printf()

There is a local definition for snprintf() which might have this support
for you. Look in backend/port/snprintf.c

- run_ruletest - the difference is only in the name that is selected
from the tables
- many other tests failed due to not having the dynamicly loaded code
in DLLs

Is DLL support so different that it will never work, or have you not had
time to look at it?

I would like to list NT as being "supported with patches, see web site"
for the next release (or "partially supported..."). Is it premature to
do that?

Good work btw...

- Tom

changes are version independent. The main difference from

other port is

the renamed system table pg_version (vs. PG_VERSION) to

pg_ver - Windows

I thought Windows allowed any case, so you could open a file with
"PG_VERSION" or "pg_version" and it will open any file of any matching
case.

The problem is that there exists file PG_VERSION where is the current
version stored (now 6.4) in the directory ./data/base/template1 and when
the bootstrap code wants to create pg_version system table it stops
because the file with the "same" name already exists.

That is a good point. Actually template1/pg_version is never used,
because it is used for a 'version' command we don't support, and I don't
think ever worked. Perhaps I will remove the file.

What would you like done with this patch? Should it merged into the
tree, or just used for people testing things on NT, and later
merged in
as you feel more comfortable? You can make a 6.4 final
patch, perhaps.

I think we should wait for the final 6.4 version (I hope it will be soon
available) and than make a patch against it and include it also in the
6.5 development tree. There are some open issues yet.

I run the regression tests yesterday, the results are here:
=============== running regression queries... =================
boolean .. ok
char .. ok
name .. ok
varchar .. ok
text .. ok
strings .. ok
int2 .. failed
int4 .. failed
int8 .. failed
oid .. ok
float4 .. ok
float8 .. failed
numerology .. failed
point .. ok
lseg .. ok
box .. ok
path .. ok
polygon .. ok
circle .. ok
geometry .. failed
timespan .. ok
datetime .. failed
reltime .. ok
abstime .. failed
tinterval .. failed
horology .. failed
comments .. ok
create_function_1 .. ok
create_type .. ok
create_table .. ok
create_function_2 .. failed
constraints .. failed
triggers .. failed
copy .. ok
create_misc .. ok
create_aggregate .. ok
create_operator .. ok
create_view .. ok
create_index .. ok
sanity_check .. ok
errors .. ok
select .. ok
select_into .. ok
select_distinct .. ok
select_distinct_on .. ok
select_implicit .. ok
select_having .. ok
subselect .. ok
union .. failed
aggregates .. ok
transactions .. ok
random .. ok
portals .. ok
misc .. failed
arrays .. ok
btree_index .. ok
hash_index .. ok
select_views .. ok
alter_table .. ok
portals_p2 .. ok
setup_ruletest .. ok
run_ruletest .. failed

now some explanations:
- int2, int4 - there are OK but there is a problem with the error
messages from libc
- int8 - the libc does probably have no support for long long ints in
printf()
- run_ruletest - the difference is only in the name that is selected
from the tables
- many other tests failed due to not having the dynamicly loaded code in
DLLs

We have all these problems on most platforms, except for the last one.

Good job.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@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

- run_ruletest - the difference is only in the name that is selected
from the tables
- many other tests failed due to not having the dynamicly loaded code
in DLLs

Is DLL support so different that it will never work, or have you not had
time to look at it?

I would like to list NT as being "supported with patches, see web site"
for the next release (or "partially supported..."). Is it premature to
do that?

Good questions. I think for NT, we may have to just supply a binary on
the web site, as I think the tools need for the port may not be
available for normal NT sites. That is OK, because there is only on NT
binary (for i386, at least, and NT 4.0).

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@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

Hi,

I have successeed in porting PostgreSQL to Win NT. The patch that is
included is for development version from Sep 15, but I think that the
changes are version independent. The main difference from other port is
the renamed system table pg_version (vs. PG_VERSION) to pg_ver - Windows
file names are case insensitive :-) So this should be solved on a global
level perhaps in main sources. And also the communication through
AF_UNIX sockets is disabled. There are only two other changes:
- added some flag while opening directory with open() syscall
- changed flags for file descriptor in function pq_init()
and that's all :-)

I have removed the data/base/*/pg_version file because it was never
used. We had removed the 'version' functions long ago, but
include/catalog/pg_version.h was still being processed by genbki.sh. No
longer. backend/command/version.c is also no longer compiled.

This should make your table changes unnecessary.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@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

Hello Bruce

On Oct 8, 5:40pm, Bruce Momjian wrote:

I have removed the data/base/*/pg_version file because it was never
used. We had removed the 'version' functions long ago, but

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Does this mean that the following from the FAQ is wrong?

3.25) How do I tell what PostgreSQL version I am running?

From psql, type select version();

If so then this question should probably be changed to point users to the
PG_VERSION file.

Just a thought

--
Sincerely,

Jazzman (a.k.a. Justin Hickey) e-mail: jhickey@hpcc.nectec.or.th
High Performance Computing Center
National Electronics and Computer Technology Center (NECTEC)
Bangkok, Thailand
==================================================================
People who think they know everything are very irritating to those
of us who do. ---Anonymous

Jazz and Trek Rule!!!
==================================================================

Jazzman wrote:

Hello Bruce

On Oct 8, 5:40pm, Bruce Momjian wrote:

I have removed the data/base/*/pg_version file because it was never
used. We had removed the 'version' functions long ago, but

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Does this mean that the following from the FAQ is wrong?

3.25) How do I tell what PostgreSQL version I am running?

From psql, type select version();

If so then this question should probably be changed to point users to the
PG_VERSION file.

No, it is still correct. The version function is there and it
returns the compiled in string from version.h.

But take a look at version.c please. I think it should use
memcpy() or strncpy() instead of strcpy(). As it is now it
writes the null byte after the palloc'ed area.

Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#======================================== jwieck@debis.com (Jan Wieck) #

Most of us aren't NT propellerheads, but now that a port might be
available I'm sure the mailing lists will get more folks who
are. Then a
tremendous step forward such as you've take will be greeted with more
enthusiasm :)

My primary development is Linux/i386 but NT with Cugwin is almost Unix -
command line utilities, gcc, ... And the clients want M$...

- many other tests failed due to not having the dynamicly

loaded code

in DLLs

Is DLL support so different that it will never work, or have
you not had
time to look at it?

It is only not so simple to create shared library in Cygwin as in Linux.
There are some makefiles that creates DLL "automagicly". It needs 5
step, 2 or 3 temporary files but it possible... There can be "DLL in
Cygwin" gurus ...

Dan Horak

I would like to list NT as being "supported with patches,

see web site"

for the next release (or "partially supported..."). Is it

premature to

do that?

Good questions. I think for NT, we may have to just supply a
binary on
the web site, as I think the tools need for the port may not be
available for normal NT sites. That is OK, because there is
only on NT
binary (for i386, at least, and NT 4.0).

The tools are from:
Cygwin B19 (http://www.cygnus.com/misc/gnu-win32/) - it makes Unix from
Windows :-)
EGCS 1.1 (http://www.xraylith.wisc.edu/~khan/software/gnu-win32/)
CygIPC library v 1.01 from Ludovic Lange
(http://www.multione.capgemini.fr/tools/pack_ipc/)
Some headers missing in Cygwin I took from Linux/Intel - can be
distributed as patch for standard Cygwin enviroment

I have the files (~0.9 MB) created after "make install" ready but I
don't know now what else is needed (in addition to cygwinb19.dll,
/etc/passwd and SYSV IPC stuff) - it has to be first experimentaly found
:-)

Dan Horak

No, it is still correct. The version function is there and it
returns the compiled in string from version.h.

But take a look at version.c please. I think it should use
memcpy() or strncpy() instead of strcpy(). As it is now it
writes the null byte after the palloc'ed area.

Yes, thanks. Fixed using StrNCpy().

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@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