Sending out a request for more buildfarm animals?
Hi,
There's pretty little coverage of non mainstream platforms/compilers in
the buildfarm atm. Maybe we should send an email on -announce asking for
new ones?
There's no coverage for OS-wise;
* AIX (at all)
* HP-UX (for master at least)
(* Tru64)
(* UnixWare)
Architecture wise there's no coverage for:
* some ARM architecture varians
* mips
* s390/x
* sparc 32bit
(* s390)
(* alpha)
(* mipsel)
(* M68K)
A couple of those aren't that important (my opinion indicated by ()),
but the other ones really should be covered or desupported.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Fri, May 02, 2014 at 05:04:01PM +0200, Andres Freund wrote:
There's pretty little coverage of non mainstream platforms/compilers in
the buildfarm atm. Maybe we should send an email on -announce asking for
new ones?
There's no coverage for OS-wise;
* AIX (at all)
* HP-UX (for master at least)
(* Tru64)
(* UnixWare)Architecture wise there's no coverage for:
* some ARM architecture varians
* mips
* s390/x
* sparc 32bit
(* s390)
(* alpha)
(* mipsel)
(* M68K)A couple of those aren't that important (my opinion indicated by ()),
but the other ones really should be covered or desupported.
More coverage of non-gcc compilers would be an asset to the buildfarm.
+1 for sending a call for help to -announce. I agree with your importance
estimates, particularly on the OS side. -1 for making code-level changes to
"desupport" a platform based on the lack of a buildfarm member, though I don't
mind documentation/advocacy changes on that basis.
--
Noah Misch
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 2014-05-02 21:07:55 -0400, Noah Misch wrote:
On Fri, May 02, 2014 at 05:04:01PM +0200, Andres Freund wrote:
There's pretty little coverage of non mainstream platforms/compilers in
the buildfarm atm. Maybe we should send an email on -announce asking for
new ones?
There's no coverage for OS-wise;
* AIX (at all)
* HP-UX (for master at least)
(* Tru64)
(* UnixWare)Architecture wise there's no coverage for:
* some ARM architecture varians
* mips
* s390/x
* sparc 32bit
(* s390)
(* alpha)
(* mipsel)
(* M68K)A couple of those aren't that important (my opinion indicated by ()),
but the other ones really should be covered or desupported.More coverage of non-gcc compilers would be an asset to the buildfarm.
+1 for sending a call for help to -announce. I agree with your importance
estimates, particularly on the OS side. -1 for making code-level changes to
"desupport" a platform based on the lack of a buildfarm member, though I don't
mind documentation/advocacy changes on that basis.
I was thinking of changing
http://www.postgresql.org/docs/devel/static/supported-platforms.html to
list untested platforms similar to the way M32R and VAX are
documented. I.e. code exists, but we have no clue whether it works.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Hamid@EDB; Can you please have someone configure anole to build git
head as well as the other branches? Thanks.
Andres, Andrew; I think the only other gap EDB could fill at the
moment is RHEL6 on Power7 (though we do have a couple of Power8 boxes
on order that should be here pretty soon). Dotterel is building some
branches (including head). I'm not sure what generation of Power CPU
that box has. Bernd?
On Fri, May 2, 2014 at 4:04 PM, Andres Freund <andres@2ndquadrant.com> wrote:
Hi,
There's pretty little coverage of non mainstream platforms/compilers in
the buildfarm atm. Maybe we should send an email on -announce asking for
new ones?
There's no coverage for OS-wise;
* AIX (at all)
* HP-UX (for master at least)
(* Tru64)
(* UnixWare)Architecture wise there's no coverage for:
* some ARM architecture varians
* mips
* s390/x
* sparc 32bit
(* s390)
(* alpha)
(* mipsel)
(* M68K)A couple of those aren't that important (my opinion indicated by ()),
but the other ones really should be covered or desupported.Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Dave Page
Chief Architect, Tools & Installers
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
It's a POWER 7 machine.
On 3. Mai 2014 10:31:34 MESZ, Dave Page <dave.page@enterprisedb.com> wrote:
Hamid@EDB; Can you please have someone configure anole to build git
head as well as the other branches? Thanks.Andres, Andrew; I think the only other gap EDB could fill at the
moment is RHEL6 on Power7 (though we do have a couple of Power8 boxes
on order that should be here pretty soon). Dotterel is building some
branches (including head). I'm not sure what generation of Power CPU
that box has. Bernd?On Fri, May 2, 2014 at 4:04 PM, Andres Freund <andres@2ndquadrant.com>
wrote:Hi,
There's pretty little coverage of non mainstream platforms/compilers
in
the buildfarm atm. Maybe we should send an email on -announce asking
for
new ones?
There's no coverage for OS-wise;
* AIX (at all)
* HP-UX (for master at least)
(* Tru64)
(* UnixWare)Architecture wise there's no coverage for:
* some ARM architecture varians
* mips
* s390/x
* sparc 32bit
(* s390)
(* alpha)
(* mipsel)
(* M68K)A couple of those aren't that important (my opinion indicated by ()),
but the other ones really should be covered or desupported.Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services--
Dave Page
Chief Architect, Tools & Installers
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL CompanyBlog: http://pgsnake.blogspot.com
Twitter: @pgsnake
--
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
On Sat, May 03, 2014 at 10:09:56AM +0200, Andres Freund wrote:
On 2014-05-02 21:07:55 -0400, Noah Misch wrote:
+1 for sending a call for help to -announce. I agree with your importance
estimates, particularly on the OS side. -1 for making code-level changes to
"desupport" a platform based on the lack of a buildfarm member, though I don't
mind documentation/advocacy changes on that basis.I was thinking of changing
http://www.postgresql.org/docs/devel/static/supported-platforms.html to
list untested platforms similar to the way M32R and VAX are
documented. I.e. code exists, but we have no clue whether it works.
Sounds perfect.
--
Noah Misch
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 3.5.2014 03:07, Noah Misch wrote:
More coverage of non-gcc compilers would be an asset to the buildfarm.
Does that include non-gcc compilers on Linux/x86 platforms?
Magpie is pretty much dedicated to the buildfarm, and it's pretty much
doing nothing most of the time, so running the tests with other
compilers (llvm/ic/...) would be just fine. Not sure how to do that,
though. Should I run the tests with multiple configurations, or should
we have one animal for each config?
Tomas
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Tomas Vondra <tv@fuzzy.cz> writes:
Magpie is pretty much dedicated to the buildfarm, and it's pretty much
doing nothing most of the time, so running the tests with other
compilers (llvm/ic/...) would be just fine. Not sure how to do that,
though. Should I run the tests with multiple configurations, or should
we have one animal for each config?
I believe the intent is one animal name per configuration.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 05/03/2014 12:42 PM, Tomas Vondra wrote:
On 3.5.2014 03:07, Noah Misch wrote:
More coverage of non-gcc compilers would be an asset to the buildfarm.
Does that include non-gcc compilers on Linux/x86 platforms?
Magpie is pretty much dedicated to the buildfarm, and it's pretty much
doing nothing most of the time, so running the tests with other
compilers (llvm/ic/...) would be just fine. Not sure how to do that,
though. Should I run the tests with multiple configurations, or should
we have one animal for each config?
No, don't run with multiple configs. That makes it much harder to see
where problems come from. One animal per config, please.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 3.5.2014 19:01, Andrew Dunstan wrote:
On 05/03/2014 12:42 PM, Tomas Vondra wrote:
On 3.5.2014 03:07, Noah Misch wrote:
More coverage of non-gcc compilers would be an asset to the buildfarm.
Does that include non-gcc compilers on Linux/x86 platforms?
Magpie is pretty much dedicated to the buildfarm, and it's pretty much
doing nothing most of the time, so running the tests with other
compilers (llvm/ic/...) would be just fine. Not sure how to do that,
though. Should I run the tests with multiple configurations, or should
we have one animal for each config?No, don't run with multiple configs. That makes it much harder to see
where problems come from. One animal per config, please.
Yeah, that's what I thought.
I've requested another animal for clang, I'll do the same with the intel
compiler once I get the clang one running.
Are there any other compilers / something else we could run on this box?
regards
Tomas
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Andres,
There's pretty little coverage of non mainstream platforms/compilers in
the buildfarm atm. Maybe we should send an email on -announce asking for
new ones?
There's no coverage for OS-wise;
* AIX (at all)
* HP-UX (for master at least)
(* Tru64)
(* UnixWare)
Do we want a SmartOS (opensolaris/Joyent) animal? Do we already have one?
Architecture wise there's no coverage for:
* some ARM architecture varians
I could run a buildfarm animal on a Raspberry Pi if the Postgres
community will replace my flash cards as they burn out.
* mips
* s390/x
* sparc 32bit
Do we really care about sparc 32bit at this point? You're talking a
10-year-old machine, there.
(* s390)
(* alpha)
(* mipsel)
(* M68K)A couple of those aren't that important (my opinion indicated by ()),
but the other ones really should be covered or desupported.Greetings,
Andres Freund
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Import Notes
Reply to msg id not found: WMd9dde864ccf71b5bc736d7be5b0b30db4992bb007d97c6a957b3344da0dc1e04ec003ebd6250d3d20edbf2aeedaa9ff7@asav-3.01.com
On Sun, May 4, 2014 at 9:35 PM, Josh Berkus <josh@agliodbs.com> wrote:
Architecture wise there's no coverage for:
* some ARM architecture variansI could run a buildfarm animal on a Raspberry Pi if the Postgres
community will replace my flash cards as they burn out.
Heikki already does that - it's chipmunk.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
On 05/04/2014 11:13 PM, Magnus Hagander wrote:
On Sun, May 4, 2014 at 9:35 PM, Josh Berkus <josh@agliodbs.com> wrote:
Architecture wise there's no coverage for:
* some ARM architecture variansI could run a buildfarm animal on a Raspberry Pi if the Postgres
community will replace my flash cards as they burn out.Heikki already does that - it's chipmunk.
Michael Paquier's hamster is also a Raspberry Pi.
- Heikki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Mon, May 5, 2014 at 3:40 PM, Heikki Linnakangas
<hlinnakangas@vmware.com> wrote:
On 05/04/2014 11:13 PM, Magnus Hagander wrote:
On Sun, May 4, 2014 at 9:35 PM, Josh Berkus <josh@agliodbs.com> wrote:
Architecture wise there's no coverage for:
* some ARM architecture variansI could run a buildfarm animal on a Raspberry Pi if the Postgres
community will replace my flash cards as they burn out.Heikki already does that - it's chipmunk.
Michael Paquier's hamster is also a Raspberry Pi.
Yep, using Archlinux for the PI, Heikki's stuff plays with Raspbian.
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Hi,
On 2014-05-04 12:35:44 -0700, Josh Berkus wrote:
There's pretty little coverage of non mainstream platforms/compilers in
the buildfarm atm. Maybe we should send an email on -announce asking for
new ones?
There's no coverage for OS-wise;
* AIX (at all)
* HP-UX (for master at least)
(* Tru64)
(* UnixWare)Do we want a SmartOS (opensolaris/Joyent) animal? Do we already have one?
I don't think so. We only have solaris 10 afaics.
* mips
* s390/x
* sparc 32bitDo we really care about sparc 32bit at this point? You're talking a
10-year-old machine, there.
I personally don't really, but the last time it came up significant
parts of community opinionated the other way. And I'd rather have it
tested and actually supported than supposedly supported.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Andres Freund wrote:
* sparc 32bit
Do we really care about sparc 32bit at this point? You're talking a
10-year-old machine, there.I personally don't really, but the last time it came up significant
parts of community opinionated the other way. And I'd rather have it
tested and actually supported than supposedly supported.
The thing is that a machine as weird as Sparc uncovers strange failures
that don't show up in other architectures. For instance, spoonbill
(sparc64 IIRC) has turned up rather interesting numbers of problems.
I think it's useful to have such a thing in the buildfarm.
--
�lvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 4.5.2014 21:29, Tomas Vondra wrote:
On 3.5.2014 19:01, Andrew Dunstan wrote:
On 05/03/2014 12:42 PM, Tomas Vondra wrote:
On 3.5.2014 03:07, Noah Misch wrote:
More coverage of non-gcc compilers would be an asset to the buildfarm.
Does that include non-gcc compilers on Linux/x86 platforms?
Magpie is pretty much dedicated to the buildfarm, and it's pretty much
doing nothing most of the time, so running the tests with other
compilers (llvm/ic/...) would be just fine. Not sure how to do that,
though. Should I run the tests with multiple configurations, or should
we have one animal for each config?No, don't run with multiple configs. That makes it much harder to see
where problems come from. One animal per config, please.Yeah, that's what I thought.
I've requested another animal for clang, I'll do the same with the intel
compiler once I get the clang one running.Are there any other compilers / something else we could run on this box?
OK, both new animals are up and apparently running - treepie for clang,
fulmar for icc.
I recall there was a call for more animals with CLOBBER_CACHE_ALWAYS
some time ago, so I went and enabled that on all three animals. Let's
see how long that will take.
I see there are more 'clobber' options in the code: CLOBBER_FREED_MEMORY
and CLOBBER_CACHE_RECURSIVELY. Would that be a good idea to enable these
as well?
The time requirements will be much higher (especially for the
RECURSIVELY option), but running that once a week shouldn't be a big
deal - the machine is pretty much dedicated to the buildfarm.
regards
Tomas
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Tomas Vondra <tv@fuzzy.cz> writes:
I recall there was a call for more animals with CLOBBER_CACHE_ALWAYS
some time ago, so I went and enabled that on all three animals. Let's
see how long that will take.
I see there are more 'clobber' options in the code: CLOBBER_FREED_MEMORY
and CLOBBER_CACHE_RECURSIVELY. Would that be a good idea to enable these
as well?
The time requirements will be much higher (especially for the
RECURSIVELY option), but running that once a week shouldn't be a big
deal - the machine is pretty much dedicated to the buildfarm.
I've never had the patience to run the regression tests to completion with
CLOBBER_CACHE_RECURSIVELY at all, let alone do it on a regular basis.
(I wonder if there's some easy way to run it for just a few regression
tests...)
I think testing CLOBBER_FREED_MEMORY would be sensible though.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 6.5.2014 22:24, Tom Lane wrote:
Tomas Vondra <tv@fuzzy.cz> writes:
I recall there was a call for more animals with CLOBBER_CACHE_ALWAYS
some time ago, so I went and enabled that on all three animals. Let's
see how long that will take.I see there are more 'clobber' options in the code: CLOBBER_FREED_MEMORY
and CLOBBER_CACHE_RECURSIVELY. Would that be a good idea to enable these
as well?The time requirements will be much higher (especially for the
RECURSIVELY option), but running that once a week shouldn't be a big
deal - the machine is pretty much dedicated to the buildfarm.I've never had the patience to run the regression tests to completion
with CLOBBER_CACHE_RECURSIVELY at all, let alone do it on a regular
basis. (I wonder if there's some easy way to run it for just a few
regression tests...)
Now, that's a challenge ;-)
I think testing CLOBBER_FREED_MEMORY would be sensible though.
OK, I've enabled this for now.
Tomas
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 6.5.2014 23:01, Tomas Vondra wrote:
On 6.5.2014 22:24, Tom Lane wrote:
Tomas Vondra <tv@fuzzy.cz> writes:
I recall there was a call for more animals with CLOBBER_CACHE_ALWAYS
some time ago, so I went and enabled that on all three animals. Let's
see how long that will take.I see there are more 'clobber' options in the code: CLOBBER_FREED_MEMORY
and CLOBBER_CACHE_RECURSIVELY. Would that be a good idea to enable these
as well?The time requirements will be much higher (especially for the
RECURSIVELY option), but running that once a week shouldn't be a big
deal - the machine is pretty much dedicated to the buildfarm.I've never had the patience to run the regression tests to completion
with CLOBBER_CACHE_RECURSIVELY at all, let alone do it on a regular
basis. (I wonder if there's some easy way to run it for just a few
regression tests...)Now, that's a challenge ;-)
I think testing CLOBBER_FREED_MEMORY would be sensible though.
OK, I've enabled this for now.
Hmmmm, with CLOBBER_CACHE_ALWAYS + CLOBBER_FREED_MEMORY the tests take
~20h on a single branch/animal. With a single locale (e.g. "C") it would
take ~4h, but we're testing a bunch of additional czech/slovak locales.
The tests are running in sequence (magpie->treepie->fulmar) so with all
6 branches, this would take ~14 days to complete. I don't mind the
machine is running tests 100% of the time, that's why it's in buildfarm,
but I'd rather see the failures soon after the commit (and two weeks is
well over the "soon" edge, IMHO).
So I'm thinking about how to improve this. I'd like to keep the options
for all the branches (e.g. not just HEAD, as a few other animals do).
But I'm thinking about running the tests in parallel, somehow - the
machine has 4 cores, and most of the time only one of them is used. I
don't expect a perfect ~3x speedup, but getting ~2x would be nice.
Any recommendations how to do that? I see there's 'base_port' in the
config - is it enough to tweak this, or do I need to run separate the
animals using e.g. lxc?
regards
Tomas
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
