Skip site navigation (1) Skip section navigation (2)

Re: Porting to Haiku

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Mark Hellegers <mhellege(at)xs4all(dot)nl>, Postgresql Hackers Mailinglist <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Porting to Haiku
Date: 2013-01-12 22:40:06
Message-ID: 50F1E646.6050406@dunslane.net (view raw or flat)
Thread:
Lists: pgsql-hackers
On 01/12/2013 04:07 PM, Tom Lane wrote:
> "Mark Hellegers" <mhellege(at)xs4all(dot)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



In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2013-01-12 22:50:00
Subject: Re: Porting to Haiku
Previous:From: Tom LaneDate: 2013-01-12 21:36:39
Subject: Re: Re: [PATCH] unified frontend support for pg_malloc et al and palloc/pfree mulation (was xlogreader-v4)

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group