Greg Stark wrote:
Jan Wieck [EMAIL PROTECTED] writes:
the point is that PostgreSQL is no GNU product, never has been and if someone
intends to he shall do so after yanking out the contributions I made.
Note that when you released your contributions you did so under a license that
imposed no such
Jan Wieck wrote:
Greg Stark wrote:
Jan Wieck [EMAIL PROTECTED] writes:
the point is that PostgreSQL is no GNU product, never has been and if someone
intends to he shall do so after yanking out the contributions I made.
Note that when you released your contributions you did so
Bruce Momjian wrote:
Jan Wieck wrote:
Greg Stark wrote:
Jan Wieck [EMAIL PROTECTED] writes:
the point is that PostgreSQL is no GNU product, never has been and if someone
intends to he shall do so after yanking out the contributions I made.
Note that when you released your contributions
Jan Wieck wrote:
Bruce Momjian wrote:
Jan Wieck wrote:
Greg Stark wrote:
Jan Wieck [EMAIL PROTECTED] writes:
the point is that PostgreSQL is no GNU product, never has been and if someone
intends to he shall do so after yanking out the contributions I made.
Note that
Jan Wieck [EMAIL PROTECTED] writes:
the point is that PostgreSQL is no GNU product, never has been and if someone
intends to he shall do so after yanking out the contributions I made.
Note that when you released your contributions you did so under a license that
imposed no such conditions. If
Greg Stark wrote:
imposed no such conditions. If Microsoft wanted to release a Microsoft
Postgresql under a completely proprietary license they would be free
to do
I have often wondered, in a completely off-topic and unproductive sort
of way, if exactly that has not already been done by an
Merlin Moncure [EMAIL PROTECTED] wrote:
Greg Stark wrote:
imposed no such conditions. If Microsoft wanted to release a
Microsoft Postgresql under a completely proprietary license they
would be free
to do
I have often wondered, in a completely off-topic and unproductive sort
of way, if exactly
-Original Message-
From: Merlin Moncure [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 03, 2004 12:28 PM
To: Greg Stark
Cc: [EMAIL PROTECTED]
Subject: Re: [pgsql-hackers-win32] [HACKERS] What's left?
Greg Stark wrote:
imposed no such conditions. If Microsoft wanted
] What's left?
Dann Corbit wrote:
But for now I suggest that the default prefix on Windows is
C:\Program Files\PostgreSQL
More properly:
%ProgramFiles%\PostgreSQL
Another suggestion: %ProgramFiles%\PGDG\PostgreSQL (or even
%ProgramFiles%\PGDG\PostgreSQL 7.5). Apache2 uses %ProgramFiles%\Apache
Group
Jan Wieck [mailto:[EMAIL PROTECTED]
(BSent: 2004$BG/(J2$B7n(J2$BF|(J 10:34
(BTo: Steve Tibbett
(BCc: 'David Garamond'; 'Dann Corbit'; 'Claudio Natoli'; 'Andrew Dunstan';
(B'pgsql-hackers-win32'; 'PostgreSQL-development'
(BSubject: Re: [pgsql-hackers-win32] [HACKERS] What's left?
(
Dann Corbit wrote:
I may be able to help on the localization and path stuff. We have
solved those issues for our port of 7.1.3, and I expect the work for 7.5
to be extremely similar.
Where can I get the latest tarball for Win32 development?
CVS HEAD now has all the Win32 work.
--
Bruce
pgman wrote:
PeerDirect handles rename by just looping. We really can't delay a
rename. There is discussion in the Win32 TODO detail that goes over
some options, I think.
Do we really have any problem with rename? We don't rename table files.
The renames I can think of are
Bruce Momjian [EMAIL PROTECTED] writes:
In this way, no one ever has the rename file open while we are holding
the locks, and we can loop without holding an exclusive lock on
pg_shadow, and file writes remain in order.
You're doing this where exactly, and are certain that you are holding no
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
In this way, no one ever has the rename file open while we are holding
the locks, and we can loop without holding an exclusive lock on
pg_shadow, and file writes remain in order.
You're doing this where exactly, and are certain that
Tom Lane wrote:
Claudio Natoli [EMAIL PROTECTED] writes:
One important thing I forgot, that someone could start looking at now:
* backends keeping files open when other backends are trying to
delete/rename them
We must do better for the official port,
Why? The procedure you
Bruce Momjian [EMAIL PROTECTED] writes:
I think it will very likely rename/unlink will fail because of the file
descriptor cache kept by each backend.
Hmm ... you're probably right. Okay, it's a more significant issue than
I thought.
I am attaching dir.c from the PeerDirect port. It handles
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
I think it will very likely rename/unlink will fail because of the file
descriptor cache kept by each backend.
Hmm ... you're probably right. Okay, it's a more significant issue than
I thought.
I am attaching dir.c from the
Dann Corbit wrote:
But for now I suggest that the default prefix on Windows is
C:\Program Files\PostgreSQL
More properly:
%ProgramFiles%\PostgreSQL
Another suggestion: %ProgramFiles%\PGDG\PostgreSQL (or even
%ProgramFiles%\PGDG\PostgreSQL 7.5). Apache2 uses %ProgramFiles%\Apache
Group\Apache2.
Hello,
I think it's safe to say there is a working implementation of a signal
handler. The one tricky part left is to identify some smart places for
the backend to check the awaiting signal queue. The first one is easy:
switch recv() with select() with a reasonable timeout and a poll.
If and
I would like very much to help any way possible in solving any last
remaining issues. Once the CVS sources are compliable, it will be
easier to make meaningful contributions. I'm really looking
forward to testing and benchmarking the win32 port. A big thanks
to all who continue to work
Claudio Natoli wrote:
* installation directory issues (/usr/local/pgsql/bin won't work too well
outside of the MingW environment :-)
Clearly we will need an installer for a binary distribution. But for now
I suggest that the default prefix on Windows is
C:\Program Files\PostgreSQL
cheers
Andrew Dunstan wrote:
Claudio Natoli wrote:
* installation directory issues (/usr/local/pgsql/bin won't work too
well outside of the MingW environment :-)
Clearly we will need an installer for a binary distribution.
Yes. To be more precise, my point was that doing so will require
Hi all,
Might I just suggest good old C:\PostgreSQL ?
MS SQL server defaults to C:\MSSQL, so I don't think that a directory in the
root path is unreasonable. Further, it makes it look more important if it
installs in the root directory :)
All the best,
-David Felstead
Claudio Natoli wrote:
Where can I get the latest tarball for Win32 development?
There isn't a specific Win32 tarball, but you can get nightly snapshots from
the usual place (ftp://ftp.postgresql.org/pub/dev/), or pull down the tip
from CVS.
Reading back through the thread though, you'll find that the code is not
Some fool wrote:
It will then be a matter of fixing things like:
* installation directory issues (/usr/local/pgsql/bin won't work too
well outside of the MingW environment :-)
* general directory handling (ie. whitespaces in directory names;
forward/backslash path canonicalization)
Might I just suggest good old C:\PostgreSQL ?
MS SQL server defaults to C:\MSSQL, so I don't think that a directory in
the
root path is unreasonable. Further, it makes it look more important if it
installs in the root directory :)
Don't do that. I hate software that does that. To me it
Claudio Natoli [EMAIL PROTECTED] writes:
One important thing I forgot, that someone could start looking at now:
* backends keeping files open when other backends are trying to
delete/rename them
We must do better for the official port,
Why? The procedure you mentioned seems perfectly
Tom Lane wrote:
Claudio Natoli [EMAIL PROTECTED] writes:
One important thing I forgot, that someone could start looking at now:
* backends keeping files open when other backends are trying to
delete/rename them
We must do better for the official port,
Why? The procedure you
28 matches
Mail list logo
