From: | Andres Freund <andres(at)2ndquadrant(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Dave McGuire <mcguire(at)neurotica(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, John Klos <john(at)ziaspace(dot)com>, port-vax(at)netbsd(dot)org, vax(at)openbsd(dot)org, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: PostgreSQL for VAX on NetBSD/OpenBSD |
Date: | 2014-06-29 14:54:34 |
Message-ID: | 20140629145434.GB26930@awork2.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2014-06-29 10:24:22 -0400, Tom Lane wrote:
> Dave McGuire <mcguire(at)neurotica(dot)com> writes:
> > On 06/25/2014 01:57 PM, Tom Lane wrote:
> >> Is there anyone in the NetBSD/VAX community who would be willing to
> >> host a PG buildfarm member?
>
> > I could put together a simh-based machine (i.e., fast) on a vm, if
> > nobody else has stepped up for this.
>
> No other volunteers have emerged, so if you'd do that it'd be great.
Maybe I'm just not playful enough, but keeping a platform alive so we
can run postgres in simulator seems a bit, well, pointless. On the other
hand VAX on *BSD isn't causing many problems that I'm aware of though,
so, whatever.
I've had a quick look and it seems netbsd emulates atomics on vax for
its own purposes (_do_cas in
https://www.almos.fr/trac/netbsdtsar/browser/vendor/netbsd/5/src/sys/arch/vax/vax/lock_stubs.S)
using a hashed lock.
Interestingly ither my nonexistant VAX knowledge is betraying me
(wouldn't be a surprise) or the algorithm doesn't test whether the lock
(bbssi) actually suceeded though...
So I don't think we'd be much worse off with the userland spinlock
protecting atomic ops.
> Probably first we ought to fix whatever needs to be fixed to get a
> standard build to go through. The one existing NetBSD machine in the
> buildfarm, coypu, doesn't seem to be using any special configuration
> hacks:
> http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=coypu&dt=2014-06-29%2012%3A33%3A12
> so I'm a bit confused as to what we need to change for VAX.
That's probably something we should fix independently though. One of the
failures was:
> gmake[2]: Leaving directory
> '/usr/pkgsrc/databases/postgresql93-server/work/postgresql-9.3.4/src/backend'
> gcc -O1 -fgcse -fstrength-reduce -fgcse-after-reload -I/usr/include
> -I/usr/local/include -Wall -Wmissing-prototypes -Wpointer-arith
> -Wdeclaration-after-statement -Wendif-labels -Wmissing-format-attribute
> -Wformat-security -fno-strict-aliasing -fwrapv -pthread -mt -D_REENTRANT
> -D_THREAD_SAFE -D_POSIX_PTHREAD_SEMANTICS -I../../src/port -DFRONTEND
> -I../../src/include -I/usr/include -I/usr/local/include -c -o thread.o
> thread.c
> cc1: error: unrecognized command line option "-mt" <builtin>: recipe for
> target 'thread.o' failed
> gmake[1]: *** [thread.o] Error 1
> gmake[1]: Leaving directory
> '/usr/pkgsrc/databases/postgresql93-server/work/postgresql-9.3.4/src/port'
> ../../../src/Makefile.global:423: recipe for target 'submake-libpgport'
which I don't really understand - we actually test all that in
acx_pthread.m4?
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2014-06-29 14:55:17 | Re: Decoding of (nearly) empty transactions and regression tests |
Previous Message | Tom Lane | 2014-06-29 14:36:22 | Re: Decoding of (nearly) empty transactions and regression tests |