On 02/07/14 08:36, Andres Freund wrote:
On 2014-07-01 20:21:37 -0400, Tom Lane wrote:
Andres Freund <and...@2ndquadrant.com> writes:
On 2014-07-01 23:21:07 +0100, Mark Cave-Ayland wrote:
Also if you're struggling for Sun buildfarm animals, recent versions of QEMU
will quite happily install and run later versions of 32-bit Solaris over
serial, and 2.0 even manages to give you a cgthree framebuffer for the full
experience.
Well. I have to admit I'm really not interested in investing that much
time in something I've no stake in. If postgres developers have to put
emulated machines to develop features something imo went seriously
wrong. That's more effort than at least I'm willing to spend.
Perhaps more to the point, I have no faith at all that an emulator will
mimic multiprocessor timing behavior to the level of detail needed to
tell whether memory-barrier-related logic works. See the VAX discussion
just a couple days ago.
Well, it would allow us to see wether fixed stuff actually compiles and
runs - that's not nothing. The biggest problem with fixing stuff like
armv5, sparc8, whatever is that it requires adding stuff to our inline
assembly. It's easy to accidentally make it not compile, but
comparatively harder to make the behaviour even worse than before.
The point I wanted to make was that there are certain applications for
which SPARCv8 is still certified for particular military/aerospace use.
While I don't use it myself, some people are still using it enough to
want to contribute QEMU patches.
In terms of QEMU, the main reason for mentioning it was that if the
consensus were to keep SPARCv8 support then this could be one possible
way to provide basic buildfarm support (although as Tom rightly points
out, there would need to be testing to build up confidence that the
emulator does the right thing in a multiprocessor environment).
ATB,
Mark.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
