Thread: 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 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. Dan Horak PS: where are you, Joost? the email for you is returning to me
Attachment
> 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
> 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!!! ==================================================================
> 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, the version command was removed. I should not have said version function. select version() works just as always. -- 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
Re: [HACKERS] version functions (was NT port of PGSQL - success)
From
jwieck@debis.com (Jan Wieck)
Date:
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) #
> 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