Thread: Porting to Haiku

Hello,

I have read the developers FAQ which directed me to this mailing list.
I am still using Postgresql on Zeta (descendant of BeOS), but it is 
becoming time to upgrade, so I installed Haiku (open source 
reimplementation of BeOS) on another machine and downloaded the 9.2.1 
source of Postgresql.
I used an older version of Postgresql which still contained the BeOS 
support to see what needed to be done to get 9.2.1 working on Haiku.
Now that I have Postgresql running (with some issues I am still 
investigating), I would like to create patches to get Haiku support 
added to the official tree of Postgresql.
I do have some questions before I submit a patch:
- Assuming all patches are applied to get Postgresql running, what does 
it require to keep it in there? I noticed you removed the BeOS port, 
because no one was maintaining it. What does it take to maintain a 
port?
- Can I submit patches for smaller parts or do I need to submit all the 
patches in one go? For example, can I submit the patch for the 
configure part first and other changes later?
- I have a problem compiling Postgresql after I installed iodbc. Iodbc 
also contains a header called sqltypes.h, which the compiler picks up 
before the one in the ecpg include directory as it is in the general 
include directory for the system. Is that something someone has seen 
before and knows what is wrong? It could be some mistake I made in my 
changes.

I am planning to get the latest sources from git and apply my patches 
on that source as I am assuming that is preferred and I don't need 
9.2.1 specifically.

Kind regards,

Mark

--
Spangalese for beginners:

`Halley mak ranfuer.'
`Your infant has swallowed my grenade.'

On 01/11/2013 04:36 PM, Mark Hellegers wrote:
> Hello,
>
> I have read the developers FAQ which directed me to this mailing list.
> I am still using Postgresql on Zeta (descendant of BeOS), but it is
> becoming time to upgrade, so I installed Haiku (open source
> reimplementation of BeOS) on another machine and downloaded the 9.2.1
> source of Postgresql.
> I used an older version of Postgresql which still contained the BeOS
> support to see what needed to be done to get 9.2.1 working on Haiku.
> Now that I have Postgresql running (with some issues I am still
> investigating), I would like to create patches to get Haiku support
> added to the official tree of Postgresql.
> I do have some questions before I submit a patch:
> - Assuming all patches are applied to get Postgresql running, what does
> it require to keep it in there? I noticed you removed the BeOS port,
> because no one was maintaining it. What does it take to maintain a
> port?
> - Can I submit patches for smaller parts or do I need to submit all the
> patches in one go? For example, can I submit the patch for the
> configure part first and other changes later?
> - I have a problem compiling Postgresql after I installed iodbc. Iodbc
> also contains a header called sqltypes.h, which the compiler picks up
> before the one in the ecpg include directory as it is in the general
> include directory for the system. Is that something someone has seen
> before and knows what is wrong? It could be some mistake I made in my
> changes.
>
> I am planning to get the latest sources from git and apply my patches
> on that source as I am assuming that is preferred and I don't need
> 9.2.1 specifically.
>


I think we'd only support a new platform prospectively, so yes, use git 
master.

You can submit patches in small parts, but I would really hope that the 
changes required are not going to be very big, so there's not a lot of 
point. If they are going to be huge it might in fact make us think twice 
about the value of supporting it.

You will make us a lot more comfortable about supporting Haiku if you 
will undertake to set up and maintain a buildfarm animal running it. One 
thing we don't want is new port that we have no way of making sure stays 
current.

cheers

andrew

"Mark Hellegers" <mhellege@xs4all.nl> writes:
> - Assuming all patches are applied to get Postgresql running, what does 
> it require to keep it in there? I noticed you removed the BeOS port, 
> because no one was maintaining it. What does it take to maintain a 
> port?

These days, the expectation is that somebody runs a buildfarm member
on that platform:
http://buildfarm.postgresql.org/index.html
You might want to look into whether you can get the buildfarm script
to run before you go too far.

> - Can I submit patches for smaller parts or do I need to submit all the 
> patches in one go? For example, can I submit the patch for the 
> configure part first and other changes later?

Well, it'd depend on how invasive the earlier patches are.  We might
want to see some evidence that the project will reach completion before
we hack up the code too much.

> - I have a problem compiling Postgresql after I installed iodbc. Iodbc 
> also contains a header called sqltypes.h, which the compiler picks up 
> before the one in the ecpg include directory as it is in the general 
> include directory for the system. Is that something someone has seen 
> before and knows what is wrong? It could be some mistake I made in my 
> changes.

Hm, I don't recall this having been reported before.  Check the order
of -I switches in the ecpg makefiles.  It certainly sounds like a risk
that we might want to fix independently of any particular port.

> I am planning to get the latest sources from git and apply my patches 
> on that source as I am assuming that is preferred and I don't need 
> 9.2.1 specifically.

Yeah, we would probably not consider back-patching such changes, so you
may as well work against master.
        regards, tom lane

> "Mark Hellegers" <mhellege@xs4all.nl> writes:
> > - Assuming all patches are applied to get Postgresql running, what 
> > does 
> > it require to keep it in there? I noticed you removed the BeOS 
> > port, 
> > because no one was maintaining it. What does it take to maintain a 
> > port?
> 
> These days, the expectation is that somebody runs a buildfarm member
> on that platform:
> http://buildfarm.postgresql.org/index.html
> You might want to look into whether you can get the buildfarm script
> to run before you go too far.

I will check that this weekend. Thanks.
Does this buildfarm member need to run continuously?

> > - Can I submit patches for smaller parts or do I need to submit all 
> > the 
> > patches in one go? For example, can I submit the patch for the 
> > configure part first and other changes later?
> 
> Well, it'd depend on how invasive the earlier patches are.  We might
> want to see some evidence that the project will reach completion 
> before
> we hack up the code too much.

I just did a quick check of my changes and the changes seem minor.  The 
only major changes are the port specific parts in src/backend/port.
Postgresql is running. I can login with psql and create a table, insert 
data and query it. ODBC access is also working. There does seem to be a 
problem with starting autovacuum, which I am still investigating.
> > - I have a problem compiling Postgresql after I installed iodbc. 
> > Iodbc 
> > also contains a header called sqltypes.h, which the compiler picks 
> > up 
> > before the one in the ecpg include directory as it is in the 
> > general 
> > include directory for the system. Is that something someone has 
> > seen 
> > before and knows what is wrong? It could be some mistake I made in 
> > my 
> > changes.
> 
> Hm, I don't recall this having been reported before.  Check the order
> of -I switches in the ecpg makefiles.  It certainly sounds like a 
> risk
> that we might want to fix independently of any particular port.

I will try to check on that this weekend.
I also found (I think) two places where the implementation of a 
function contained slightly different parameters from the declaration 
which breaks on Haiku as an int is not the same as int32 (see src/
backend/catalog/dependency.c function deleteOneObject for one of 
those).
> > I am planning to get the latest sources from git and apply my 
> > patches 
> > on that source as I am assuming that is preferred and I don't need 
> > 9.2.1 specifically.
> 
> Yeah, we would probably not consider back-patching such changes, so 
> you
> may as well work against master.
> 


--
Spangalese for beginners:

`Halley mak ranfuer.'
`Your infant has swallowed my grenade.'

"Mark Hellegers" <mhellege@xs4all.nl> writes:
>> You might want to look into whether you can get the buildfarm script
>> to run before you go too far.

> I will check that this weekend. Thanks.
> Does this buildfarm member need to run continuously?

Once a day is sufficient if that's all you can manage, though several
times a day is nicer.

> I just did a quick check of my changes and the changes seem minor.

Yeah, as Andrew remarked, it shouldn't be that hard given that the code
used to run on BeOS.  You should check the commits around where that
support was removed, if you didn't already.

> I also found (I think) two places where the implementation of a 
> function contained slightly different parameters from the declaration 
> which breaks on Haiku as an int is not the same as int32 (see src/
> backend/catalog/dependency.c function deleteOneObject for one of 
> those).

This is the sort of thing that gets noticed much quicker if there's a
buildfarm member that complains about it ...
        regards, tom lane

> "Mark Hellegers" <mhellege@xs4all.nl> writes:
> >> You might want to look into whether you can get the buildfarm 
> > > script
> >> to run before you go too far.
> 
> > I will check that this weekend. Thanks.
> > Does this buildfarm member need to run continuously?
> 
> Once a day is sufficient if that's all you can manage, though several
> times a day is nicer.

I managed to run the buildfarm script. Needed to make a small change to 
the perl script as on Haiku everyone is "root", but other than that it 
runs fine.
I have only one server available running Haiku. Can I also run a normal 
Postgresql installation on that same machine? If so, I will be able to 
run the build multiple times a day.
> > I just did a quick check of my changes and the changes seem minor.
> 
> Yeah, as Andrew remarked, it shouldn't be that hard given that the 
> code
> used to run on BeOS.  You should check the commits around where that
> support was removed, if you didn't already.

Yes, I already have done that. I think I don't need all the changes 
that were done then, but we will see.
> > I also found (I think) two places where the implementation of a 
> > function contained slightly different parameters from the 
> > declaration 
> > which breaks on Haiku as an int is not the same as int32 (see src/
> > backend/catalog/dependency.c function deleteOneObject for one of 
> > those).
> 
> This is the sort of thing that gets noticed much quicker if there's a
> buildfarm member that complains about it ...

I understand. I will start working on reapplying my patches to master. 
Git is still new to me, but I'm making progress.

Kind regards,

Mark


--
Spangalese for beginners:

`Lipsanae bully booly.'
`The Lemming is driving recklessly.'

"Mark Hellegers" <mhellege@xs4all.nl> writes:
> I have only one server available running Haiku. Can I also run a normal 
> Postgresql installation on that same machine? If so, I will be able to 
> run the build multiple times a day.

I believe that works at the moment, although there were discussions just
yesterday about whether we really wanted to support it.  (The point
being that the buildfarm script would have to be careful not to kill the
live postmaster when cleaning up after a test failure.  I would
definitely advise that you not run the buildfarm under the same userid
as any live server, so that no accidental damage is possible.)

Keep in mind though that the buildfarm run tends to suck a lot of cycles
when it's going --- you might not like the response-time hit you'll
probably see on the live server, unless this is a nice beefy machine.
        regards, tom lane

On 01/12/2013 10:07 PM, Tom Lane wrote:
> "Mark Hellegers" <mhellege@xs4all.nl> writes:
>> I have only one server available running Haiku. Can I also run a normal 
>> Postgresql installation on that same machine? If so, I will be able to 
>> run the build multiple times a day.
> 
> I believe that works at the moment, although there were discussions just
> yesterday about whether we really wanted to support it.  (The point
> being that the buildfarm script would have to be careful not to kill the
> live postmaster when cleaning up after a test failure.  I would
> definitely advise that you not run the buildfarm under the same userid
> as any live server, so that no accidental damage is possible.)

iirc Haiku is very strange in that regard - it is basically a
single-user operating system, which I think makes it basically useless
as a server and a horror from a security pov.


Stefan

On 01/12/2013 04:07 PM, Tom Lane wrote:
> "Mark Hellegers" <mhellege@xs4all.nl> writes:
>> I have only one server available running Haiku. Can I also run a normal
>> Postgresql installation on that same machine? If so, I will be able to
>> run the build multiple times a day.
> I believe that works at the moment, although there were discussions just
> yesterday about whether we really wanted to support it.  (The point
> being that the buildfarm script would have to be careful not to kill the
> live postmaster when cleaning up after a test failure.  I would
> definitely advise that you not run the buildfarm under the same userid
> as any live server, so that no accidental damage is possible.)


No, I'm never going to make it unsafe to run the buildfarm alongside a 
live server. I think you've misunderstood my intentions.

My main development machine at any time has from about three to six 
postmasters running, completely undisturbed by the buildfarm animal that 
fires every hour alongside them.

>
> Keep in mind though that the buildfarm run tends to suck a lot of cycles
> when it's going --- you might not like the response-time hit you'll
> probably see on the live server, unless this is a nice beefy machine.
>


If this is an issue, it's best to run the script when load is least 
important, like 2.00am. It's designed to run from cron.


cheers

andrew

Andrew Dunstan <andrew@dunslane.net> writes:
> On 01/12/2013 04:07 PM, Tom Lane wrote:
>> ... I would
>> definitely advise that you not run the buildfarm under the same userid
>> as any live server, so that no accidental damage is possible.)

> No, I'm never going to make it unsafe to run the buildfarm alongside a 
> live server. I think you've misunderstood my intentions.

Oh, the intention is clear enough.  But there are always bugs.  I don't
actually run any buildfarm critters myself, but if I did you can be sure
they'd be under their own userid that couldn't possibly break anything
else.
        regards, tom lane

> I understand. I will start working on reapplying my patches to 
> master. 
> Git is still new to me, but I'm making progress.
> 

I'm running into a little problem with applying my patches.
It seems I made a quick fix in my port that I can't commit and I'm not 
sure what the best way to fix this is.
The problem is that Haiku does have getrusage, but does not have all 
the fields as used in Postgresql.
If I undef HAVE_GETRUSAGE, the code that uses those fields is not 
compiled (see src/backend/trcop/postgres.c line 4338), but then it will 
include the rusagestub.h file (see line 38 of the same file). The 
rusagestub.h file contains all the definitions that already exist in 
Haiku, so then it trips over that. I commented out the include of the 
rusagestub.h file in my initial work, but that is obviously not a good 
idea as a patch. I can try to skip the include if compiling on Haiku, 
but I'm not sure this is the best way to do this.

Kind regards,

Mark

--
Spangalese for beginners:

`Geh nae?'
`Do you know the serial number on the bumper of that 1958 Thunderbird?'

On 01/13/2013 12:18 PM, Mark Hellegers wrote:
>> I understand. I will start working on reapplying my patches to
>> master.
>> Git is still new to me, but I'm making progress.
>>
> I'm running into a little problem with applying my patches.
> It seems I made a quick fix in my port that I can't commit and I'm not
> sure what the best way to fix this is.

   git commit -a


should be all you need to commit something. All commits in git are 
local, so committing your changes won't hurt anyone else.

> The problem is that Haiku does have getrusage, but does not have all
> the fields as used in Postgresql.

What is it missing?

> If I undef HAVE_GETRUSAGE, the code that uses those fields is not
> compiled (see src/backend/trcop/postgres.c line 4338), but then it will
> include the rusagestub.h file (see line 38 of the same file). The
> rusagestub.h file contains all the definitions that already exist in
> Haiku, so then it trips over that. I commented out the include of the
> rusagestub.h file in my initial work, but that is obviously not a good
> idea as a patch. I can try to skip the include if compiling on Haiku,
> but I'm not sure this is the best way to do this.
>
>


I did get a haiku instance running yesterday. But I am kinda busy for a 
few days - I'll try to take a peek at this later in the week. I suggest 
you set up a repo at bitbucket or github that you can push your changes 
to so people can pull them if necessary.

cheers

andrew

> 
> On 01/13/2013 12:18 PM, Mark Hellegers wrote:
> >> I understand. I will start working on reapplying my patches to
> >> master.
> >> Git is still new to me, but I'm making progress.
> >>
> > I'm running into a little problem with applying my patches.
> > It seems I made a quick fix in my port that I can't commit and I'm 
> > not
> > sure what the best way to fix this is.
> 
> 
>     git commit -a
> 
> 
> should be all you need to commit something. All commits in git are 
> local, so committing your changes won't hurt anyone else.

Yes, I got that. It's quite different from subversion, which is what I 
am used to.
> > The problem is that Haiku does have getrusage, but does not have 
> > all
> > the fields as used in Postgresql.
> 
> What is it missing?

It complains that the structure rusage is missing the following fields:
- ru_inblock
- ru_outblock
- ru_majflt
- ru_minflt
- ru_nswap
- ru_nsignals
- ru_msgrcv
- ru_msgsnd
- ru_nvcsw
- ru_nivcsw

I typed them over from the error output, so I may be missing one or 
mistyped something.
> > If I undef HAVE_GETRUSAGE, the code that uses those fields is not
> > compiled (see src/backend/trcop/postgres.c line 4338), but then it 
> > will
> > include the rusagestub.h file (see line 38 of the same file). The
> > rusagestub.h file contains all the definitions that already exist 
> > in
> > Haiku, so then it trips over that. I commented out the include of 
> > the
> > rusagestub.h file in my initial work, but that is obviously not a 
> > good
> > idea as a patch. I can try to skip the include if compiling on 
> > Haiku,
> > but I'm not sure this is the best way to do this.
> >
> >
> 
> 
> I did get a haiku instance running yesterday. But I am kinda busy for 
> a 
> few days - I'll try to take a peek at this later in the week. I 
> suggest 
> you set up a repo at bitbucket or github that you can push your 
> changes 
> to so people can pull them if necessary.
> 

I had a quick look at github and saw that there is a mirror of the 
postgresl project on there, but I'm not sure how to make everything 
work. I'm afraid I'm a bit too new to git to have that up and running 
without some help.
If you could help me a bit with that (perhaps off list would be best), 
I would like to give it a try.

Kind regards,

Mark


--
Spangalese for beginners:

`Wiggilo wagel hoggle?'
`Where can I scrub my eyeballs?'