Jason Tishler wrote:
>
> 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
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 Window
TECTED]>
To: "Igor 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: [HACKE
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.
> >
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
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 w
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.
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 wond
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 co
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
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 2
Bruce 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:
&
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
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 p
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 i
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 i
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 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
> activel
"Igor Kovalenko" <[EMAIL PROTECTED]> writes:
>> Could we get away with saying that the Unix-socket-less platforms have
>> weaker protection against mistakenly restarting the postmaster?
> Why can't we use named pipe (aka FIFO file) instead of UDS?
That's exactly what I'm talking about.
> Anothe
> "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 ..
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*, bu
"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
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 port
"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
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 soc
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
"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 attach
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.
"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
; Cc: Marc G. Fournier; [EMAIL PROTECTED]
> > 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
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 wo
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 secu
> -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
>
>
> &
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]
> > Subje
> 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'
> > > 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 ther
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 buildin
> (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
> > 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 p
"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
> -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]> wri
> "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
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
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 t
"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 Sy
> -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
>
>
> Ra
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 th
"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
> "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 --
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.
Tom Lane wrote:
>
> mlw <[EMAIL PROTECTED]> writes:
> > I am writing a Win32 DLL implementation of :
>
> > int
"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
co
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
> 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
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
---
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);
i
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
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
"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
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
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 ..
"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 con
On Fri, 3 May 2002, Tom Lane wrote:
> "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 curre
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:
> 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 th
rd, but alot 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]
]]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
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 wil
"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 O
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 chang
69 matches
Mail list logo
