Обсуждение: 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
Вложения
> 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)
От
jwieck@debis.com (Jan Wieck)
Дата:
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