PostgreSQL for VAX on NetBSD/OpenBSD

classic Classic list List threaded Threaded
52 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Re: PostgreSQL for VAX on NetBSD/OpenBSD

Robert Haas
On Wed, Jun 25, 2014 at 1:05 PM, John Klos <[hidden email]> wrote:

>> In any case I'm coming to the conclusion that there's little point in
>> us keeping the VAX-specific code in our source tree, because in fact,
>> this port is broken and doesn't work.  Based on your results thus far,
>> I doubt that it would be a huge amount of work to fix that, but unless
>> somebody from the VAX community wants to volunteer to be a PostgreSQL
>> maintainer for that platform, straighten out the things that have
>> gotten broken since this port was originally added, and keep it
>> working on an ongoing basis, it's probably not going to happen.
>
> While I wouldn't be surprised if you remove the VAX code because not many
> people are going to be running PostgreSQL, I'd disagree with the assessment
> that this port is broken. It compiles, it initializes databases, it runs, et
> cetera, albeit not with the default postgresql.conf.

Well, the fact that initdb didn't produce a working configuration and
that make installcheck failed to work properly are bad.  But, yeah,
it's not totally broken.

> I'm actually rather impressed at how well PostgreSQL can be adjusted to
> lower memory systems. I deploy a lot of embedded systems with 128 megs (a
> lot for an embedded system, but nothing compared with what everyone else
> assumes), so I'll be checking out PostgreSQL for other uses.

I agree, that's cool.

> NetBSD's VAX port does lots to help ensure code portability and code
> correctness, so it's not going anywhere any time soon. It certainly is a
> good sign that PostgreSQL can run on a VAX with only 20 MB or so of resident
> memory.

Yeah!

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Reply | Threaded
Open this post in threaded view
|

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

Tom Lane
Robert Haas <[hidden email]> writes:
> On Wed, Jun 25, 2014 at 1:05 PM, John Klos <[hidden email]> wrote:
>> While I wouldn't be surprised if you remove the VAX code because not many
>> people are going to be running PostgreSQL, I'd disagree with the assessment
>> that this port is broken. It compiles, it initializes databases, it runs, et
>> cetera, albeit not with the default postgresql.conf.

> Well, the fact that initdb didn't produce a working configuration and
> that make installcheck failed to work properly are bad.  But, yeah,
> it's not totally broken.

>> I'm actually rather impressed at how well PostgreSQL can be adjusted to
>> lower memory systems. I deploy a lot of embedded systems with 128 megs (a
>> lot for an embedded system, but nothing compared with what everyone else
>> assumes), so I'll be checking out PostgreSQL for other uses.

> I agree, that's cool.

I think we'd be happy to keep the VAX port of PG going as long as we
get regular feedback on it, ie closed-loop maintenance not open-loop ;-)

Is there anyone in the NetBSD/VAX community who would be willing to
host a PG buildfarm member?
http://buildfarm.postgresql.org/index.html

The requirements for this beyond what it takes to build from source
are basically just working git and Perl (ccache helps a lot too),
and enough cycles to build the code at least once a day or so.
Once you've got the thing set up it seldom needs human attention.

If we had a buildfarm member to tell us when we break things, it
would be a lot easier to promise continued support.

                        regards, tom lane

Reply | Threaded
Open this post in threaded view
|

Re: PostgreSQL for VAX on NetBSD/OpenBSD

John Klos
In reply to this post by Robert Haas
> Well, the fact that initdb didn't produce a working configuration and
> that make installcheck failed to work properly are bad.  But, yeah,
> it's not totally broken.

I think it did create a working configuration (with the exception of
postgresql.conf), because I can run psql and do stuff on the command line:

psql --username=pgsql postgres
psql (9.3.4)
Type "help" for help.

postgres=# CREATE DATABASE test;
CREATE DATABASE
postgres=# CREATE USER testuser WITH PASSWORD 'test';
CREATE ROLE
postgres=# GRANT ALL PRIVILEGES ON DATABASE test to testuser;
GRANT
postgres=# CREATE SCHEMA testschema;
CREATE SCHEMA
postgres=# CREATE TABLE testschema.testtable (testserial serial PRIMARY
KEY, testchar varchar (100) NOT NULL);
CREATE TABLE

I don't know enough to really test this. Can you recommend a simple script
to do some PostgreSQL testing?

John

Reply | Threaded
Open this post in threaded view
|

Re: PostgreSQL for VAX on NetBSD/OpenBSD

Robert Haas
On Wed, Jun 25, 2014 at 1:58 PM, John Klos <[hidden email]> wrote:
>> Well, the fact that initdb didn't produce a working configuration and
>> that make installcheck failed to work properly are bad.  But, yeah,
>> it's not totally broken.
>
> I think it did create a working configuration (with the exception of
> postgresql.conf), because I can run psql and do stuff on the command line:

Yeah, but postgresql.conf should not have require manual tweaking...

> I don't know enough to really test this. Can you recommend a simple script
> to do some PostgreSQL testing?

Well, this is what 'make installcheck' is for...

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Reply | Threaded
Open this post in threaded view
|

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

Dave McGuire
In reply to this post by Tom Lane
On 06/25/2014 01:57 PM, Tom Lane wrote:

> Robert Haas <[hidden email]> writes:
>> On Wed, Jun 25, 2014 at 1:05 PM, John Klos <[hidden email]> wrote:
>>> While I wouldn't be surprised if you remove the VAX code because not many
>>> people are going to be running PostgreSQL, I'd disagree with the assessment
>>> that this port is broken. It compiles, it initializes databases, it runs, et
>>> cetera, albeit not with the default postgresql.conf.
>
>> Well, the fact that initdb didn't produce a working configuration and
>> that make installcheck failed to work properly are bad.  But, yeah,
>> it's not totally broken.
>
>>> I'm actually rather impressed at how well PostgreSQL can be adjusted to
>>> lower memory systems. I deploy a lot of embedded systems with 128 megs (a
>>> lot for an embedded system, but nothing compared with what everyone else
>>> assumes), so I'll be checking out PostgreSQL for other uses.
>
>> I agree, that's cool.
>
> I think we'd be happy to keep the VAX port of PG going as long as we
> get regular feedback on it, ie closed-loop maintenance not open-loop ;-)
>
> Is there anyone in the NetBSD/VAX community who would be willing to
> host a PG buildfarm member?
> http://buildfarm.postgresql.org/index.html
>
> The requirements for this beyond what it takes to build from source
> are basically just working git and Perl (ccache helps a lot too),
> and enough cycles to build the code at least once a day or so.
> Once you've got the thing set up it seldom needs human attention.
>
> If we had a buildfarm member to tell us when we break things, it
> would be a lot easier to promise continued support.

  I could put together a simh-based machine (i.e., fast) on a vm, if
nobody else has stepped up for this.

               -Dave

--
Dave McGuire, AK4HZ/3
New Kensington, PA

Reply | Threaded
Open this post in threaded view
|

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

Tom Lane
Dave McGuire <[hidden email]> 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.

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.

> Dave McGuire, AK4HZ/3
> New Kensington, PA

Hey, right up the river from here!

                        regards, tom lane

Reply | Threaded
Open this post in threaded view
|

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

Martin Husemann
On Sun, Jun 29, 2014 at 10:24:22AM -0400, Tom Lane wrote:
> 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.

Dave did use NetBSD 6.1 (IIRC), which uses an ancient gcc version.
I would suggest to go for NetBSD-current (if someone sets it up before
the netbsd-7 branch, or 7 post-branch), which uses gcc 4.8.3 on vax.

All other architectures already used a more modern gcc on 6.
However, there is still a bit of fallout to fix in -current.

Martin

Reply | Threaded
Open this post in threaded view
|

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

Andres Freund
In reply to this post by Tom Lane
On 2014-06-29 10:24:22 -0400, Tom Lane wrote:
> Dave McGuire <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

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

Tom Lane
Andres Freund <[hidden email]> writes:
> Maybe I'm just not playful enough, but keeping a platform alive so we
> can run postgres in simulator seems a bit, well, pointless.

True --- an actual machine would be more useful, even if slower.  Some
of the existing buildfarm critters are pretty slow already, so that's
not a huge hindrance AFAIK.

> That's probably something we should fix independently though. One of the
> failures was:
>> cc1: error: unrecognized command line option "-mt" <builtin>: recipe for
>> target 'thread.o' failed
> which I don't really understand - we actually test all that in
> acx_pthread.m4?

Yeah.  We'd need to look at the relevant part of config.log to be sure,
but my guess is that configure tried that switch, failed to recognize
that it wasn't actually working, and seized on it as what to use.
Maybe the test-for-workingness isn't quite right for this platform.

                        regards, tom lane

Reply | Threaded
Open this post in threaded view
|

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

Dave McGuire
In reply to this post by Andres Freund
On 06/29/2014 10:54 AM, Andres Freund 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.

  There are a couple of points.

  First and foremost is portability.  Using as many architectures as
possible as test platforms "keeps us honest" and can be a highly
valuable tool for early discovery of portability issues or "iffy" code
constructs.  The VAX in particular is an "extreme example" of many
aspects of processor architecture, and as such, is an excellent tool for
that sort of thing.

  Next, some people actually want to *run* it on a VAX.  Maybe for hobby
reasons, maybe for "approved platform" reasons, whatever...We don't know
(and don't care) why.

  On the "in a simulator" matter: It's important to keep in mind that
there are more VAXen out there than just simulated ones.  I'm offering
up a simulated one here because I can spin it up in a dedicated VM on a
VMware host that's already running and I already have power budget for.
 I could just as easily run it on real hardware...there are, at last
count, close to forty real-iron VAXen here, but only a few of those are
running 24/7.  I'd happily bring up another one to do Postgres builds
and testing, if someone will send me the bucks to pay for the additional
power and cooling.  (that is a real offer)

                 -Dave

--
Dave McGuire, AK4HZ/3
New Kensington, PA

Reply | Threaded
Open this post in threaded view
|

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

Tom Lane
Dave McGuire <[hidden email]> writes:
> On 06/29/2014 10:54 AM, Andres Freund wrote:
>> 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 "in a simulator" matter: It's important to keep in mind that
> there are more VAXen out there than just simulated ones.  I'm offering
> up a simulated one here because I can spin it up in a dedicated VM on a
> VMware host that's already running and I already have power budget for.
>  I could just as easily run it on real hardware...there are, at last
> count, close to forty real-iron VAXen here, but only a few of those are
> running 24/7.  I'd happily bring up another one to do Postgres builds
> and testing, if someone will send me the bucks to pay for the additional
> power and cooling.  (that is a real offer)

Well, the issue from our point of view is that a lot of what we care about
testing is extremely low-level hardware behavior, like whether spinlocks
work as expected across processors.  It's not clear that a simulator would
provide a sufficiently accurate emulation.

OTOH, the really nasty issues like cache coherency rules don't arise in
single-processor systems.  So unless you have a multiprocessor VAX
available to spin up, a simulator may tell us as much as we'd learn
anyway.

(If you have got one, maybe some cash could be found --- we do have
project funds available, and I think they'd be well spent on testing
purposes.  I don't make those decisions though.)

                        regards, tom lane

Reply | Threaded
Open this post in threaded view
|

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

Patrick Finnegan
Last I checked, NetBSD doesn't support any sort of multiprocessor VAX.
 Multiprocessor VAXes exist, but you're stuck with either Ultrix or VMS on
them.

Pat


On Sun, Jun 29, 2014 at 2:06 PM, Tom Lane <[hidden email]> wrote:

> Dave McGuire <[hidden email]> writes:
> > On 06/29/2014 10:54 AM, Andres Freund wrote:
> >> 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 "in a simulator" matter: It's important to keep in mind that
> > there are more VAXen out there than just simulated ones.  I'm offering
> > up a simulated one here because I can spin it up in a dedicated VM on a
> > VMware host that's already running and I already have power budget for.
> >  I could just as easily run it on real hardware...there are, at last
> > count, close to forty real-iron VAXen here, but only a few of those are
> > running 24/7.  I'd happily bring up another one to do Postgres builds
> > and testing, if someone will send me the bucks to pay for the additional
> > power and cooling.  (that is a real offer)
>
> Well, the issue from our point of view is that a lot of what we care about
> testing is extremely low-level hardware behavior, like whether spinlocks
> work as expected across processors.  It's not clear that a simulator would
> provide a sufficiently accurate emulation.
>
> OTOH, the really nasty issues like cache coherency rules don't arise in
> single-processor systems.  So unless you have a multiprocessor VAX
> available to spin up, a simulator may tell us as much as we'd learn
> anyway.
>
> (If you have got one, maybe some cash could be found --- we do have
> project funds available, and I think they'd be well spent on testing
> purposes.  I don't make those decisions though.)
>
>                         regards, tom lane

Reply | Threaded
Open this post in threaded view
|

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

Dave McGuire
On 06/29/2014 02:58 PM, Patrick Finnegan wrote:
> Last I checked, NetBSD doesn't support any sort of multiprocessor VAX.
>  Multiprocessor VAXes exist, but you're stuck with either Ultrix or VMS
> on them.

  Hi Pat, it's good to see your name in my inbox.

  NetBSD ran on multiprocessor BI-bus VAXen many, many years ago.  Is
that support broken?

                -Dave

--
Dave McGuire, AK4HZ/3
New Kensington, PA

Reply | Threaded
Open this post in threaded view
|

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

Andres Freund
On June 29, 2014 9:01:27 PM CEST, Dave McGuire <[hidden email]> wrote:

>On 06/29/2014 02:58 PM, Patrick Finnegan wrote:
>> Last I checked, NetBSD doesn't support any sort of multiprocessor
>VAX.
>>  Multiprocessor VAXes exist, but you're stuck with either Ultrix or
>VMS
>> on them.
>
>  Hi Pat, it's good to see your name in my inbox.
>
>  NetBSD ran on multiprocessor BI-bus VAXen many, many years ago.  Is
>that support broken?

The new atomics code refers to a VAX SMP define... So somebody seems to have thought about it not too long ago.

Andres

Andres

--
Please excuse brevity and formatting - I am writing this on my mobile phone.

Andres Freund                   http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

Reply | Threaded
Open this post in threaded view
|

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

Patrick Finnegan
In reply to this post by Dave McGuire
On Sun, Jun 29, 2014 at 3:01 PM, Dave McGuire <[hidden email]> wrote:

> On 06/29/2014 02:58 PM, Patrick Finnegan wrote:
> > Last I checked, NetBSD doesn't support any sort of multiprocessor VAX.
> >  Multiprocessor VAXes exist, but you're stuck with either Ultrix or VMS
> > on them.
>
>   Hi Pat, it's good to see your name in my inbox.
>

Hi! :)


>
>
  NetBSD ran on multiprocessor BI-bus VAXen many, many years ago.  Is
> that support broken?
>

And it also runs on the 11/780 which can have multiple CPUs... but I've
never seen support for using more than one CPU (and the NetBSD page still
says "NetBSD/vax can only make use of one CPU on multi-CPU machines").  If
that has changed, I'd love to hear about it.  Support for my VAX 6000 would
also be nice...
.

Pat

Reply | Threaded
Open this post in threaded view
|

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

Dave McGuire
In reply to this post by Tom Lane
On 06/29/2014 02:06 PM, Tom Lane wrote:
> Well, the issue from our point of view is that a lot of what we care about
> testing is extremely low-level hardware behavior, like whether spinlocks
> work as expected across processors.  It's not clear that a simulator would
> provide a sufficiently accurate emulation.

  Oh ok, I understand.  Thank you for the clarification.

> OTOH, the really nasty issues like cache coherency rules don't arise in
> single-processor systems.  So unless you have a multiprocessor VAX
> available to spin up, a simulator may tell us as much as we'd learn
> anyway.
>
> (If you have got one, maybe some cash could be found --- we do have
> project funds available, and I think they'd be well spent on testing
> purposes.  I don't make those decisions though.)

  I have several multiprocessor VAXen, but only one of them is capable
of running NetBSD, and I only (currently) have a single processor in
that machine.  I can (and want to) fix that, but not right away.

              -Dave

--
Dave McGuire, AK4HZ/3
New Kensington, PA

Reply | Threaded
Open this post in threaded view
|

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

Dave McGuire
In reply to this post by Patrick Finnegan
On 06/29/2014 03:10 PM, Patrick Finnegan wrote:
> And it also runs on the 11/780 which can have multiple CPUs... but I've
> never seen support for using more than one CPU (and the NetBSD page
> still says "NetBSD/vax can only make use of one CPU on multi-CPU
> machines").  If that has changed, I'd love to hear about it.  Support
> for my VAX 6000 would also be nice...

  It changed well over a decade ago, if memory serves.  The specific
work was done on a VAX-8300 or -8350.  I'm pretty sure the 11/780's
specific flavor of SMP is not supported.  (though I do have a pair of
11/785s here...wanna come hack? ;))

               -Dave

--
Dave McGuire, AK4HZ/3
New Kensington, PA

Reply | Threaded
Open this post in threaded view
|

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

Dave McGuire
In reply to this post by Tom Lane
On 06/29/2014 10:24 AM, 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.

  Ok, I am certainly willing to do it.  Though I haven't used PostgreSQL
in quite awhile, I ran it A LOT back when its query language was
PostQUEL, and later when it was known as Postgres95.  It'd give me a
serious "warm fuzzy" to be able to support the project in some way.

>> Dave McGuire, AK4HZ/3
>> New Kensington, PA
>
> Hey, right up the river from here!

  Come on up and hack!  There's always something neat going on around
here.  Ever run a PDP-11?  B-)

                 -Dave

--
Dave McGuire, AK4HZ/3
New Kensington, PA

Reply | Threaded
Open this post in threaded view
|

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

Patrick Finnegan
In reply to this post by Dave McGuire
On Sun, Jun 29, 2014 at 3:12 PM, Dave McGuire <[hidden email]> wrote:

> On 06/29/2014 03:10 PM, Patrick Finnegan wrote:
> > And it also runs on the 11/780 which can have multiple CPUs... but I've
> > never seen support for using more than one CPU (and the NetBSD page
> > still says "NetBSD/vax can only make use of one CPU on multi-CPU
> > machines").  If that has changed, I'd love to hear about it.  Support
> > for my VAX 6000 would also be nice...
>
>   It changed well over a decade ago, if memory serves.  The specific
> work was done on a VAX-8300 or -8350.  I'm pretty sure the 11/780's
> specific flavor of SMP is not supported.  (though I do have a pair of
> 11/785s here...wanna come hack? ;))
>

If it works, someone should update the documentation. :)

Which flavor of 11/78x MP? The official DEC kind (which is really just two
computers with a block of shared memory) or the Purdue kind (which isn't
quite SMP, but actually shares the system bus)?

Pat

Reply | Threaded
Open this post in threaded view
|

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

John Klos
In reply to this post by Tom Lane
> Well, the issue from our point of view is that a lot of what we care about
> testing is extremely low-level hardware behavior, like whether spinlocks
> work as expected across processors.  It's not clear that a simulator would
> provide a sufficiently accurate emulation.
>
> OTOH, the really nasty issues like cache coherency rules don't arise in
> single-processor systems.  So unless you have a multiprocessor VAX
> available to spin up, a simulator may tell us as much as we'd learn
> anyway.
>
> (If you have got one, maybe some cash could be found --- we do have
> project funds available, and I think they'd be well spent on testing
> purposes.  I don't make those decisions though.)

Depending on how often you'd like the system to try to run a compile, I'd
be happy to run it on a VAXstation 4000/60. It runs bulk package builds
for pkgsrc, but we could do a compile every week or so (every day would
really eat into cycles for other packages).

John

123