Jason Tishler wrote:
On Sun, Jun 02, 2002 at 09:33:57PM -0400, mlw wrote:
Bruce Momjian wrote:
mlw wrote:
Like I told Marc, I don't care. You spec out what you want and I'll write
it for Windows.
That being said, a SysV IPC interface for native Windows would be kind of
Momjian [EMAIL PROTECTED]
To: mlw [EMAIL PROTECTED]
Cc: Tom Lane [EMAIL PROTECTED]; Marc G. Fournier [EMAIL PROTECTED];
[EMAIL PROTECTED]
Sent: Sunday, June 02, 2002 8:49 PM
Subject: Re: [HACKERS] HEADS UP: Win32/OS2/BeOS native ports
mlw wrote:
Like I told Marc, I don't care. You spec out
Yes, I am having trouble figuring out if I have seen the whole thread yet.
---
Marc G. Fournier wrote:
You might want to go to the archives and catch up on the whole thread and
its digressions :)
On Sun, 2 Jun 2002,
You might want to go to the archives and catch up on the whole thread and
its digressions :)
On Sun, 2 Jun 2002, Bruce Momjian wrote:
mlw wrote:
Like I told Marc, I don't care. You spec out what you want and I'll write it
for Windows.
That being said, a SysV IPC interface for native
Bruce Momjian wrote:
mlw wrote:
Like I told Marc, I don't care. You spec out what you want and I'll write it
for Windows.
That being said, a SysV IPC interface for native Windows would be kind of cool
to have.
I am wondering why we don't just use the Cygwin shm/sem code in our
Bruce,
On Sun, Jun 02, 2002 at 08:49:21PM -0400, Bruce Momjian wrote:
mlw wrote:
Like I told Marc, I don't care. You spec out what you want and I'll write it
for Windows.
That being said, a SysV IPC interface for native Windows would be kind of
cool to have.
I am wondering why we
On Sun, Jun 02, 2002 at 09:33:57PM -0400, mlw wrote:
Bruce Momjian wrote:
mlw wrote:
Like I told Marc, I don't care. You spec out what you want and I'll write
it for Windows.
That being said, a SysV IPC interface for native Windows would be kind of
cool to have.
I am
Jason Tishler wrote:
On Sun, Jun 02, 2002 at 09:33:57PM -0400, mlw wrote:
Bruce Momjian wrote:
mlw wrote:
Like I told Marc, I don't care. You spec out what you want and I'll write
it for Windows.
That being said, a SysV IPC interface for native Windows would be kind of
Hi,
You may want to have a look at: http://www.garret.ru/~knizhnik/
You find there code for a 'Fast synchronized access to shared
memory for Windows and for i86 Unix-es.
kind regards,
Robert
Bruce,
On Sun, Jun 02, 2002 at 08:49:21PM -0400, Bruce Momjian wrote:
mlw wrote:
Like I told
On Mon, Jun 03, 2002 at 09:36:51AM -0400, mlw wrote:
Jason Tishler wrote:
On Sun, Jun 02, 2002 at 09:33:57PM -0400, mlw wrote:
Bruce Momjian wrote:
mlw wrote:
Like I told Marc, I don't care. You spec out what you want and I'll
write it for Windows.
That being
Kovalenko [EMAIL PROTECTED]
Cc: Tom Lane [EMAIL PROTECTED]; mlw [EMAIL PROTECTED]; Marc G.
Fournier [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Sunday, June 02, 2002 7:47 PM
Subject: Re: [HACKERS] HEADS UP: Win32/OS2/BeOS native ports
Igor Kovalenko wrote:
It does not have to be anonymous. POSIX also
Igor Kovalenko wrote:
It does not have to be anonymous. POSIX also defines shm_open(same arguments
as open) API which will create named object in whatever location corresponds
to shared memory storage on that platform (object is then grown to needed
size by ftruncate() and the fd is then
mlw wrote:
Like I told Marc, I don't care. You spec out what you want and I'll write it
for Windows.
That being said, a SysV IPC interface for native Windows would be kind of cool
to have.
I am wondering why we don't just use the Cygwin shm/sem code in our
project, or maybe the Apache
On Mon, 6 May 2002, Tom Lane wrote:
As a backend is started up, connect to that socket ... if socket is open
when trying to start a new frontend, fail as there are currently other
connections attached to it?
But the backends would only have the socket open, they'd not be
actively
Matthew Kirkwood [EMAIL PROTECTED] writes:
Nobody actually needs to connect to the socket. Simple,
race-free, 10 lines of code.
... and we already do it. But it protects the port number, not
the data directory.
regards, tom lane
---(end of
On Tue, 7 May 2002, Tom Lane wrote:
Nobody actually needs to connect to the socket. Simple,
race-free, 10 lines of code.
... and we already do it. But it protects the port number, not
the data directory.
If I understood him correctly, Marc was suggesting a further
domain socket inside
Matthew Kirkwood [EMAIL PROTECTED] writes:
... and we already do it. But it protects the port number, not
the data directory.
If I understood him correctly, Marc was suggesting a further
domain socket inside the data directory.
Right, and that would work because we would reference it as
Marc G. Fournier wrote:
hr ... do you have a working Windows development environment? I'm
running WinXP at home, but don't have any of the compilers or anything
yet, so all my work for the first part is going to be done under Unix ...
but someone that knows something about building
Rather than propagating the SysV semaphore API still further,
why don't
we kill it now? (I'm willing to keep the shmem API, however.)
Would this have the benefit of allow PostgreSQL to work properly in BSD
jails, since lack of really working SysV IPC was the problem there?
I have
I forwarded the suggestion to my ISP (imeme, a Zope provider), who said
that:
This will allow you to run a single postgres in a single jail only one
user would have access to it. If you try to run more then one it will
try to use the same shared memory and crash.
Not true. But I'll
On Sat, 4 May 2002, Joel Burton wrote:
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Tom Lane
Sent: Friday, May 03, 2002 6:07 PM
To: mlw
Cc: Marc G. Fournier; [EMAIL PROTECTED]
Subject: Re: [HACKERS] HEADS UP: Win32/OS2/BeOS native ports
-Original Message-
From: Christopher Kings-Lynne [mailto:[EMAIL PROTECTED]]
Sent: Monday, May 06, 2002 7:36 AM
To: Joel Burton; Tom Lane; mlw
Cc: Marc G. Fournier; [EMAIL PROTECTED]
Subject: Re: [HACKERS] HEADS UP: Win32/OS2/BeOS native ports
I forwarded the suggestion to my ISP
On Sat, 4 May 2002, Tom Lane wrote:
Matthew Kirkwood [EMAIL PROTECTED] writes:
On Fri, 3 May 2002, Tom Lane wrote:
The SysV API lets us detect that case, but I don't see any
equally good way to do it if we are using anonymous shared memory.
It's a hack (and has slight security
On Sun, 5 May 2002, Joel Burton wrote:
Joel Burton [EMAIL PROTECTED] writes:
Rather than propagating the SysV semaphore API still further, why don't
we kill it now? (I'm willing to keep the shmem API, however.)
Would this have the benefit of allow PostgreSQL to work properly in BSD
]
Subject: Re: [HACKERS] HEADS UP: Win32/OS2/BeOS native ports
I forwarded the suggestion to my ISP (imeme, a Zope provider), who said
that:
This will allow you to run a single postgres in a single jail only one
user would have access to it. If you try to run more then one
Marc G. Fournier [EMAIL PROTECTED] writes:
We could get around this, of course: record the port number in the data
directory lockfile, and test for existence of the old socket
independently of trying to create a new one. But it seems ugly.
How about a second, data directory based socket
On Mon, 6 May 2002, Tom Lane wrote:
Marc G. Fournier [EMAIL PROTECTED] writes:
We could get around this, of course: record the port number in the data
directory lockfile, and test for existence of the old socket
independently of trying to create a new one. But it seems ugly.
How about
Marc G. Fournier [EMAIL PROTECTED] writes:
Hmm ... but how do you use that to tell if there are still backends
around?
As a backend is started up, connect to that socket ... if socket is open
when trying to start a new frontend, fail as there are currently other
connections attached to it?
I said:
But the backends would only have the socket open, they'd not be actively
listening to it. So how could you tell whether anyone had the socket
open or not?
Oh, I take that back, I see how you could do it: the postmaster opens
the socket *for writing*, but never actually writes. All
On Mon, 6 May 2002, Tom Lane wrote:
I said:
But the backends would only have the socket open, they'd not be actively
listening to it. So how could you tell whether anyone had the socket
open or not?
Oh, I take that back, I see how you could do it: the postmaster opens
the socket *for
Marc G. Fournier [EMAIL PROTECTED] writes:
That would work ... but is it more portable than depending on SysV
shmem connection counts? ISTR that some of the platforms we support
don't have Unix-style sockets at all.
Wouldn't the same thing work with a simple file? Does it have to be a
Since our default behavior (at startup) is to have TCP sockets disabled,
how many OSs are there that don't support UD sockets? Enough to really be
worried about?
On Mon, 6 May 2002, Tom Lane wrote:
Marc G. Fournier [EMAIL PROTECTED] writes:
That would work ... but is it more portable
Marc G. Fournier [EMAIL PROTECTED] writes:
Since our default behavior (at startup) is to have TCP sockets disabled,
how many OSs are there that don't support UD sockets?
A quick look in the sources shows that we #undef HAVE_UNIX_SOCKETS for
QNX, BeOS, and old cygwin versions ... which are
Tom Lane wrote:
I said:
But the backends would only have the socket open, they'd not be actively
listening to it. So how could you tell whether anyone had the socket
open or not?
Oh, I take that back, I see how you could do it: the postmaster opens
the socket *for writing*, but never
Marc G. Fournier [EMAIL PROTECTED] writes:
Since our default behavior (at startup) is to have TCP sockets disabled,
how many OSs are there that don't support UD sockets?
A quick look in the sources shows that we #undef HAVE_UNIX_SOCKETS for
QNX, BeOS, and old cygwin versions ... which are
Joel Burton [EMAIL PROTECTED] writes:
Rather than propagating the SysV semaphore API still further, why don't
we kill it now? (I'm willing to keep the shmem API, however.)
Would this have the benefit of allow PostgreSQL to work properly in BSD
jails, since lack of really working SysV
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]]
Sent: Friday, May 03, 2002 3:07 PM
To: mlw
Cc: Marc G. Fournier; [EMAIL PROTECTED]
Subject: Re: [HACKERS] HEADS UP: Win32/OS2/BeOS native ports
mlw [EMAIL PROTECTED] writes:
I am writing a Win32 DLL implementation
Joel Burton [EMAIL PROTECTED] writes:
Would this have the benefit of allow PostgreSQL to work properly in BSD
jails, since lack of really working SysV IPC was the problem there?
Was the problem just with semas, or was shmem an issue too?
Not sure -- doesn't get far enough for me to tell.
Rather than propagating the SysV semaphore API still further, why don't
we kill it now? (I'm willing to keep the shmem API, however.)
Would this have the benefit of allow PostgreSQL to work properly in BSD
jails, since lack of really working SysV IPC was the problem there?
I have
(For others: apparently PG will work under BSD jails if you recompile the
BSD kernel w/some new settings, but my ISP for this project was
unwilling to
do that. Search the mailing list for messages on how to do this.)
Works fine. You don't need to recompile - just use the sysctl.
Chris
On Fri, 3 May 2002, Tom Lane wrote:
But what we must *not* do is allow a new postmaster to start while the
old backends are still running; that would mean two sets of backends
running without contact with each other, which would be fatal for data
integrity. The SysV API lets us detect that
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Tom Lane
Sent: Friday, May 03, 2002 6:07 PM
To: mlw
Cc: Marc G. Fournier; [EMAIL PROTECTED]
Subject: Re: [HACKERS] HEADS UP: Win32/OS2/BeOS native ports
Rather than propagating the SysV semaphore
Joel Burton [EMAIL PROTECTED] writes:
Rather than propagating the SysV semaphore API still further, why don't
we kill it now? (I'm willing to keep the shmem API, however.)
Would this have the benefit of allow PostgreSQL to work properly in BSD
jails, since lack of really working SysV IPC
Matthew Kirkwood [EMAIL PROTECTED] writes:
On Fri, 3 May 2002, Tom Lane wrote:
The SysV API lets us detect that case, but I don't see any
equally good way to do it if we are using anonymous shared memory.
It's a hack (and has slight security implications), but you
could just allow the
I have just committed changes to create a platform-independent internal
API for semaphores, along the lines discussed yesterday.
At this point, the Darwin (Mac OS X), BeOS, and QNX4 ports are probably
broken. I will fix the Darwin port (probably not till tomorrow though);
volunteers to clean up
Morning all ...
Just a heads up that over the next little while, I'm planning on
making a bunch of commits in order to work on making the code able to work
natively in the above environments ... my work will mostly focus on Win32
(since I have no OS2/BeOS installs), but alot of the
Marc G. Fournier wrote:
Morning all ...
Just a heads up that over the next little while, I'm planning on
making a bunch of commits in order to work on making the code able to work
natively in the above environments ... my work will mostly focus on Win32
(since I have no OS2/BeOS
On Fri, 3 May 2002, mlw wrote:
Marc G. Fournier wrote:
Morning all ...
Just a heads up that over the next little while, I'm planning on
making a bunch of commits in order to work on making the code able to work
natively in the above environments ... my work will mostly focus
]]On Behalf Of Marc G. Fournier
Sent: Friday, May 03, 2002 9:48 AM
To: mlw
Cc: [EMAIL PROTECTED]
Subject: Re: [HACKERS] HEADS UP: Win32/OS2/BeOS native ports
On Fri, 3 May 2002, mlw wrote:
Marc G. Fournier wrote:
Morning all ...
Just a heads up that over the next little while, I'm
of the core functionality that has
held back native ports should work ...
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Marc G. Fournier
Sent: Friday, May 03, 2002 9:48 AM
To: mlw
Cc: [EMAIL PROTECTED]
Subject: Re: [HACKERS] HEADS UP: Win32/OS2/BeOS
Marc G. Fournier [EMAIL PROTECTED] writes:
The initial changes will be to just wrapper all our shared memory
code, so that I can make use of Apache's libapr libraries *if* they are
installed ... if not, it will just fall back to the current code ...
I think we should redesign the shared
Hi Marc,
How about using Dev-C++?
It's a Windows IDE with a GCC backend, and has a nice rep (and a Linux
port):
http://sourceforge.net/projects/dev-cpp/
It's always in SF.net's Top 10 most worked on projects too, with about
roughly 7,000 downloads per day. It can generate mingwin code too.
Marc G. Fournier [EMAIL PROTECTED] writes:
All I'm planning on doing is changing the appropriate shm_* functions iwth
pg_shm_* functions ... if !(libapr), all those pg_shm_* functions will
have in them is the original call we've always used ... there will even be
a --disable-libapr configure
On Fri, 3 May 2002, Tom Lane wrote:
Marc G. Fournier [EMAIL PROTECTED] writes:
All I'm planning on doing is changing the appropriate shm_* functions iwth
pg_shm_* functions ... if !(libapr), all those pg_shm_* functions will
have in them is the original call we've always used ... there
Tom Lane wrote:
Marc G. Fournier [EMAIL PROTECTED] writes:
All I'm planning on doing is changing the appropriate shm_* functions iwth
pg_shm_* functions ... if !(libapr), all those pg_shm_* functions will
have in them is the original call we've always used ... there will even be
a
Marc G. Fournier wrote:
On Fri, 3 May 2002, Tom Lane wrote:
Marc G. Fournier [EMAIL PROTECTED] writes:
All I'm planning on doing is changing the appropriate shm_* functions iwth
pg_shm_* functions ... if !(libapr), all those pg_shm_* functions will
have in them is the original
mlw [EMAIL PROTECTED] writes:
I think that you should create a verbatim implementation of the SysV
shared memory API in native Win32. It may have to be a pgsysvshm.dll
or something like it, but I think it is the best possible approach.
Let me look at it, I may be able to have something
Tom Lane wrote:
mlw [EMAIL PROTECTED] writes:
I think that you should create a verbatim implementation of the SysV
shared memory API in native Win32. It may have to be a pgsysvshm.dll
or something like it, but I think it is the best possible approach.
Let me look at it, I may be able
sysv shm/sem
I am writing a Win32 DLL implementation of :
int semget(key_t key, int nsems, int semflg);
int semctl(int semid, int semnum, int cmd, union semun arg);
int semop(int semid, struct sembuf * sops, unsigned nsops);
int shmctl(int shmid, int cmd, struct shmid_ds *buf);
mlw [EMAIL PROTECTED] writes:
UNIX permissions will be ignored, i.e. uig/gid will be 0
Win32 has no security anyway, right? ;-)
Do you see any need for the msgxxx calls?
Is the function ipc() ever used?
Nope, and nope.
regards, tom lane
mlw [EMAIL PROTECTED] writes:
I am writing a Win32 DLL implementation of :
int semget(key_t key, int nsems, int semflg);
int semctl(int semid, int semnum, int cmd, union semun arg);
int semop(int semid, struct sembuf * sops, unsigned nsops);
Rather than propagating the SysV
Igor Kovalenko [EMAIL PROTECTED] writes:
What really need to be done is new abstraction layer which would cover SysV
API, POSIX and whatever native APIs are better for BeOS/OS2/Win32. I almost
did it last time...
Yes. I just sent off a proposal for a cleaner semaphore API --- please
comment
Igor Kovalenko [EMAIL PROTECTED] writes:
It does not have to be anonymous. POSIX also defines shm_open(same arguments
as open) API which will create named object in whatever location corresponds
to shared memory storage on that platform (object is then grown to needed
size by ftruncate() and
63 matches
Mail list logo
