Re: [HACKERS] PostgreSQL for VAX on NetBSD/OpenBSD

[Andres Freund <andres%2ndquadrant.com@localhost>]

On 2014-06-29 10:24:22 -0400, Tom Lane wrote:
> Dave McGuire <mcguire%neurotica.com@localhost> 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