Re: [HACKERS] BeOS port

I've already tried to put the exec back. But then I hit a problem with
"MyProcPort" which is not initialised in the backend and make the
backend crash. I've also found that "MyCancelKey" is set in postmaster.
Are there any others ?

Regarding the old code (6.3.2), there have been a lot of change in
DoBackend/DoExec. I really need some expert advice on what to do.

cyril

Hi alls

I'm working on a port of postgres on BeOS (www.be.com). BeOS is not
a real UNIX, but it provide a subset of the posix API. At this stage
I've a working version ofit. But since 6.4.2, I've a lot of problems
(dynamic loading doesn't work any more...) with the fact that
postgresmain is call directly instead of the old exec method. BeOS
really don't like to do a lot of thing after a fork and before an

exec

:=(.
I would like to know how hard it would be to add the exec call. As
I understand it, I have to get back all global variables and shared
memory and perhaps doing something with sockets/file descriptors ?

I've

a ready solution for shared memory but I need some help regarding

the

others points.

You can put back the exec fairly easily. You just need to pass the
proper parameters, and change the fork to an exec. You can look at

the

older code that did the exec for an example, and #ifdef the exec()

back

[Charset ISO-8859-1 unsupported, filtering to ASCII...]

I've already tried to put the exec back. But then I hit a problem with
"MyProcPort" which is not initialised in the backend and make the
backend crash. I've also found that "MyCancelKey" is set in postmaster.
Are there any others ?

Regarding the old code (6.3.2), there have been a lot of change in
DoBackend/DoExec. I really need some expert advice on what to do.

I recommend you get anonymous cvs access(see cvs faq on web site) do a
log to show changes to postgres.c and postmaster.c, and you will find
the exec was removed in one or two big patches. Then do a cvs diff and
see the changes made, and try and merge them into the current code with
ifdef's.

-- 
  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

Bruce Momjian <maillist@candle.pha.pa.us> writes:

Regarding the old code (6.3.2), there have been a lot of change in
DoBackend/DoExec. I really need some expert advice on what to do.

I recommend you get anonymous cvs access(see cvs faq on web site) do a
log to show changes to postgres.c and postmaster.c, and you will find
the exec was removed in one or two big patches. Then do a cvs diff and
see the changes made, and try and merge them into the current code with
ifdef's.

He's right though: there have been subsequent changes that depend on
not doing an exec(). Offhand I only recall MyCancelKey --- that is set
in the postmaster process just before fork(), and the backend simply
assumes that it's got the right value.

The straightforward solution (invent another backend command line switch
to pass the cancel key) would not be a very good idea, since that would
expose the cancel key to prying eyes.

If BeOS does not have the ability to support fork without exec, does it
have some other way of achieving the same result? Threads maybe?
(But Postgres is hardly the only common daemon that uses fork without
exec; sendmail comes to mind, for example. So it seems like the real
answer is to beat up the BeOS folks about fixing their inadequate Unix
support...)

regards, tom lane

* I've progess a bit with MyCancelKey and MyProcPort (postmaster
send all that information to the backend with a BeOS kernel port :
nothing is visible on the command line except the port number but datas
don't stays in the port more than a few milliseconds). All Shared
memory segment are also restored in the backend process. But now, I
have a crash in SpinAcquire(OidGenLockId). It seems that SLockArray is
not initialized. Do I need to send it to the backend ?

* BeOS provide a nice implementation of threads (But it's not posix
threads). It could be interesting to adapt postgres to works with
threads but there will be some work whith global variables (which will
be shared by all backends in this case), they should be transfered in
some kind of thread local storage. Is it somethong interesting to do ?

* The Be guy try to improve there posix support but the case of the
fork seem to cause some technical problems and the possible actions
between a fork and an exec are pretty limited.

cyril

I've already tried to put the exec back. But then I hit a problem

with

"MyProcPort" which is not initialised in the backend and make the
backend crash. I've also found that "MyCancelKey" is set in

postmaster.

Are there any others ?

Regarding the old code (6.3.2), there have been a lot of change in
DoBackend/DoExec. I really need some expert advice on what to do.

He's right though: there have been subsequent changes that depend on
not doing an exec(). Offhand I only recall MyCancelKey --- that is

set

in the postmaster process just before fork(), and the backend simply
assumes that it's got the right value.

The straightforward solution (invent another backend command line

switch

to pass the cancel key) would not be a very good idea, since that

would

expose the cancel key to prying eyes.

If BeOS does not have the ability to support fork without exec, does

it

have some other way of achieving the same result? Threads maybe?
(But Postgres is hardly the only common daemon that uses fork without
exec; sendmail comes to mind, for example. So it seems like the real
answer is to beat up the BeOS folks about fixing their inadequate Unix
support...)

regards, tom lane

I recommend you get anonymous cvs access(see cvs faq on web site) do a
log to show changes to postgres.c and postmaster.c, and you will find
the exec was removed in one or two big patches. Then do a cvs diff

and

see the changes made, and try and merge them into the current code

with

[Charset ISO-8859-1 unsupported, filtering to ASCII...]

* I've progess a bit with MyCancelKey and MyProcPort (postmaster
send all that information to the backend with a BeOS kernel port :
nothing is visible on the command line except the port number but datas
don't stays in the port more than a few milliseconds). All Shared
memory segment are also restored in the backend process. But now, I
have a crash in SpinAcquire(OidGenLockId). It seems that SLockArray is
not initialized. Do I need to send it to the backend ?

Yes, I think I made some changes where initialization was done only once
in the postmaster, and inherited by every fork'ed backend.
-- 
  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

On Fri, Jun 18, 1999 at 10:35:18AM -0400, Tom Lane wrote:

Bruce Momjian <maillist@candle.pha.pa.us> writes:

Regarding the old code (6.3.2), there have been a lot of change in
DoBackend/DoExec. I really need some expert advice on what to do.

I recommend you get anonymous cvs access(see cvs faq on web site) do a
log to show changes to postgres.c and postmaster.c, and you will find
the exec was removed in one or two big patches. Then do a cvs diff and
see the changes made, and try and merge them into the current code with
ifdef's.

He's right though: there have been subsequent changes that depend on
not doing an exec(). Offhand I only recall MyCancelKey --- that is set
in the postmaster process just before fork(), and the backend simply
assumes that it's got the right value.

The straightforward solution (invent another backend command line switch
to pass the cancel key) would not be a very good idea, since that would
expose the cancel key to prying eyes.

If BeOS does not have the ability to support fork without exec, does it
have some other way of achieving the same result? Threads maybe?
(But Postgres is hardly the only common daemon that uses fork without
exec; sendmail comes to mind, for example. So it seems like the real
answer is to beat up the BeOS folks about fixing their inadequate Unix
support...)

I heard that! I work in Be's QA department. In fact, our bug
database got transferred to a Postgres/PHP/Apache system a few months
ago, running on Linux. Although I'm pretty much of the mind that BeOS
isn't a server OS, it would be interesting to see BeOS running postgres
as a server.
If you can tell me specifically what the problem is, I can pass
it along to the Kernel team.