Обсуждение: RE: [HACKERS] NT port of PGSQL - success
> > 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