PostgreSQL for VAX on NetBSD/OpenBSD

[Robert Haas]

Hello VAX Enthusiasts:

PostgreSQL currently has some very minimal code to support the VAX
architecture. We have never supported OpenVMS, so this code would
only be used if someone were to compile PostgreSQL for VAX on an
operating system that we *do* support, such as NetBSD or OpenBSD.
However, we don't know of anyone who has tried to do this in a very
long time, and are therefore considering removing the remaining
support for the VAX platform. Has anyone tried to build PostgreSQL
for VAX lately? If so, did it compile? Did you have to use
--disable-spinlocks to get it to compile? If it did compile, can you
actually run it, and does it pass the regression tests and work as
expected? Would you be willing to work with the PostgreSQL to ensure
continuing support for this platform, or does that seem not worthwhile
for whatever reason?

Thanks,

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

[Greg Stark]

On Mon, Jun 23, 2014 at 3:09 PM, Robert Haas <***@gmail.com> wrote:
> However, we don't know of anyone who has tried to do this in a very
> long time, and are therefore considering removing the remaining
> support for the VAX platform. Has anyone tried to build PostgreSQL
> for VAX lately?

Actually I tried a while ago but got stuck configuring the network on
simh so I could get all the tools. I can try again if there's interest
but we don't necessarily need to keep a port just because there's a
simulator for it.


--
greg

[Dave McGuire]

On 06/23/2014 06:58 PM, Greg Stark wrote:
> On Mon, Jun 23, 2014 at 3:09 PM, Robert Haas <***@gmail.com> wrote:
>> However, we don't know of anyone who has tried to do this in a very
>> long time, and are therefore considering removing the remaining
>> support for the VAX platform. Has anyone tried to build PostgreSQL
>> for VAX lately?
>
> Actually I tried a while ago but got stuck configuring the network on
> simh so I could get all the tools. I can try again if there's interest
> but we don't necessarily need to keep a port just because there's a
> simulator for it.

...not to mention actual hardware.

-Dave

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

[Robert Haas]

On Mon, Jun 23, 2014 at 6:58 PM, Greg Stark <***@mit.edu> wrote:
> On Mon, Jun 23, 2014 at 3:09 PM, Robert Haas <***@gmail.com> wrote:
>> However, we don't know of anyone who has tried to do this in a very
>> long time, and are therefore considering removing the remaining
>> support for the VAX platform. Has anyone tried to build PostgreSQL
>> for VAX lately?
>
> Actually I tried a while ago but got stuck configuring the network on
> simh so I could get all the tools. I can try again if there's interest
> but we don't necessarily need to keep a port just because there's a
> simulator for it.

That's really up to you. I'm not particularly interested in
generating interest in maintaining this port if there wouldn't
otherwise be any; I'm trying to figure out whether there is existing
interest in it. For all I know, <whatever>BSD is shipping PostgreSQL
binaries for VAX and every other platform they support in each new
release and people are using them to get real work done. Then again,
for all I know, it doesn't even compile on that platform, and if you
did manage to get it to compile it wouldn't fit on the disk, and if
you managed to fit it on the disk it wouldn't work because key system
calls aren't supported. If someone is still interested in this, I'm
hoping they'll help us figure out whether it's anywhere close to
working, and maybe even contribute a buildfarm critter. If no one
cares, then let's just rip it out and be done with it.

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

[Sebastian Reitenbach]

On Tuesday, June 24, 2014 03:12 CEST, Robert Haas <***@gmail.com> wrote:

> On Mon, Jun 23, 2014 at 6:58 PM, Greg Stark <***@mit.edu> wrote:
> > On Mon, Jun 23, 2014 at 3:09 PM, Robert Haas <***@gmail.com> wrote:
> >> However, we don't know of anyone who has tried to do this in a very
> >> long time, and are therefore considering removing the remaining
> >> support for the VAX platform. Has anyone tried to build PostgreSQL
> >> for VAX lately?
> >
> > Actually I tried a while ago but got stuck configuring the network on
> > simh so I could get all the tools. I can try again if there's interest
> > but we don't necessarily need to keep a port just because there's a
> > simulator for it.
>
> That's really up to you. I'm not particularly interested in
> generating interest in maintaining this port if there wouldn't
> otherwise be any; I'm trying to figure out whether there is existing
> interest in it. For all I know, <whatever>BSD is shipping PostgreSQL
> binaries for VAX and every other platform they support in each new
> release and people are using them to get real work done. Then again,
> for all I know, it doesn't even compile on that platform, and if you
> did manage to get it to compile it wouldn't fit on the disk, and if
> you managed to fit it on the disk it wouldn't work because key system
> calls aren't supported. If someone is still interested in this, I'm
> hoping they'll help us figure out whether it's anywhere close to
> working, and maybe even contribute a buildfarm critter. If no one
> cares, then let's just rip it out and be done with it.
>

I'm building the vax packages for openbsd. What I can tell is that
for 5.5 no postgresql packages were built. But that may be that
due to the recent upgrade from gcc 2.95 to 3.3.
I guess that not all dependencies to actually build postgresql
are available for the vax, or may build successfully there. But I need
to verify. Might need a few days, since I'm currently on vacation,
with sparse Internet connectivity. ;)

Sebastian


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

[Sebastian Reitenbach]

On Tuesday, June 24, 2014 13:37 CEST, "Sebastian Reitenbach" <***@l00-bugdead-prods.de> wrote:

> On Tuesday, June 24, 2014 03:12 CEST, Robert Haas <***@gmail.com> wrote:
>
> > On Mon, Jun 23, 2014 at 6:58 PM, Greg Stark <***@mit.edu> wrote:
> > > On Mon, Jun 23, 2014 at 3:09 PM, Robert Haas <***@gmail.com> wrote:
> > >> However, we don't know of anyone who has tried to do this in a very
> > >> long time, and are therefore considering removing the remaining
> > >> support for the VAX platform. Has anyone tried to build PostgreSQL
> > >> for VAX lately?
> > >
> > > Actually I tried a while ago but got stuck configuring the network on
> > > simh so I could get all the tools. I can try again if there's interest
> > > but we don't necessarily need to keep a port just because there's a
> > > simulator for it.
> >
> > That's really up to you. I'm not particularly interested in
> > generating interest in maintaining this port if there wouldn't
> > otherwise be any; I'm trying to figure out whether there is existing
> > interest in it. For all I know, <whatever>BSD is shipping PostgreSQL
> > binaries for VAX and every other platform they support in each new
> > release and people are using them to get real work done. Then again,
> > for all I know, it doesn't even compile on that platform, and if you
> > did manage to get it to compile it wouldn't fit on the disk, and if
> > you managed to fit it on the disk it wouldn't work because key system
> > calls aren't supported. If someone is still interested in this, I'm
> > hoping they'll help us figure out whether it's anywhere close to
> > working, and maybe even contribute a buildfarm critter. If no one
> > cares, then let's just rip it out and be done with it.
> >
>
> I'm building the vax packages for openbsd. What I can tell is that
> for 5.5 no postgresql packages were built. But that may be that
> due to the recent upgrade from gcc 2.95 to 3.3.
> I guess that not all dependencies to actually build postgresql
> are available for the vax, or may build successfully there. But I need
> to verify. Might need a few days, since I'm currently on vacation,
> with sparse Internet connectivity. ;)

OK, that was easy:

$ cd /usr/ports/databases/postgresql
$ make install
===> postgresql-client-9.3.4p0 requires shared libraries .

OpenBSD VAX is static only, so no postgresql on OpenBSD
VAX before shared libraries will ever be made working on it.

cheers,
Sebastian


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

[Robert Haas]

On Tue, Jun 24, 2014 at 7:45 AM, Sebastian Reitenbach
<***@l00-bugdead-prods.de> wrote:
>> I'm building the vax packages for openbsd. What I can tell is that
>> for 5.5 no postgresql packages were built. But that may be that
>> due to the recent upgrade from gcc 2.95 to 3.3.
>> I guess that not all dependencies to actually build postgresql
>> are available for the vax, or may build successfully there. But I need
>> to verify. Might need a few days, since I'm currently on vacation,
>> with sparse Internet connectivity. ;)
>
> OK, that was easy:
>
> $ cd /usr/ports/databases/postgresql
> $ make install
> ===> postgresql-client-9.3.4p0 requires shared libraries .
>
> OpenBSD VAX is static only, so no postgresql on OpenBSD
> VAX before shared libraries will ever be made working on it.

Thanks very much; that's useful information.

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

[Tom Lane]

"Sebastian Reitenbach" <***@l00-bugdead-prods.de> writes:
> OK, that was easy:

> $ cd /usr/ports/databases/postgresql
> $ make install
> ===> postgresql-client-9.3.4p0 requires shared libraries .

> OpenBSD VAX is static only, so no postgresql on OpenBSD
> VAX before shared libraries will ever be made working on it.

Ouch. We long ago passed the point of no return as far as requiring
shared library support: there's too much backend functionality that's
in separate shared libraries rather than being linked directly into
the core executable. I doubt anyone will be interested in taking on
the task of supporting a parallel all-static build.

I think this means we can write off VAX on NetBSD/OpenBSD as a viable
platform for Postgres :-(. I'm sad to hear it, but certainly have
not got the cycles personally to prevent it.

regards, tom lane


--
Sent via pgsql-hackers mailing list (pgsql-***@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[Dave McGuire]

On 06/24/2014 12:42 PM, Tom Lane wrote:
> "Sebastian Reitenbach" <***@l00-bugdead-prods.de> writes:
>> OK, that was easy:
>
>> $ cd /usr/ports/databases/postgresql
>> $ make install
>> ===> postgresql-client-9.3.4p0 requires shared libraries .
>
>> OpenBSD VAX is static only, so no postgresql on OpenBSD
>> VAX before shared libraries will ever be made working on it.
>
> Ouch. We long ago passed the point of no return as far as requiring
> shared library support: there's too much backend functionality that's
> in separate shared libraries rather than being linked directly into
> the core executable. I doubt anyone will be interested in taking on
> the task of supporting a parallel all-static build.
>
> I think this means we can write off VAX on NetBSD/OpenBSD as a viable
> platform for Postgres :-(. I'm sad to hear it, but certainly have
> not got the cycles personally to prevent it.

Nonono...NetBSD/vax has had shared library support for many years.
It's only OpenBSD that has that limitation.

-Dave

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

[Tom Lane]

Dave McGuire <***@neurotica.com> writes:
> On 06/24/2014 12:42 PM, Tom Lane wrote:
>> I think this means we can write off VAX on NetBSD/OpenBSD as a viable
>> platform for Postgres :-(. I'm sad to hear it, but certainly have
>> not got the cycles personally to prevent it.

> Nonono...NetBSD/vax has had shared library support for many years.
> It's only OpenBSD that has that limitation.

Ah, thanks for the clarification.

regards, tom lane

[Alvaro Herrera]

Dave McGuire wrote:
> On 06/24/2014 12:42 PM, Tom Lane wrote:

> > I think this means we can write off VAX on NetBSD/OpenBSD as a viable
> > platform for Postgres :-(. I'm sad to hear it, but certainly have
> > not got the cycles personally to prevent it.
>
> Nonono...NetBSD/vax has had shared library support for many years.
> It's only OpenBSD that has that limitation.

So now we know that NetBSD/vax is free of the shared library limitation
that plagues OpenBSD, but does Postgres work on NetBSD/vax otherwise?

--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services


--
Sent via pgsql-hackers mailing list (pgsql-***@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[Anders Magnusson]

Tom Lane skrev 2014-06-24 18:42:
> "Sebastian Reitenbach" <***@l00-bugdead-prods.de> writes:
>> OK, that was easy:
>> $ cd /usr/ports/databases/postgresql
>> $ make install
>> ===> postgresql-client-9.3.4p0 requires shared libraries .
>> OpenBSD VAX is static only, so no postgresql on OpenBSD
>> VAX before shared libraries will ever be made working on it.
> Ouch. We long ago passed the point of no return as far as requiring
> shared library support: there's too much backend functionality that's
> in separate shared libraries rather than being linked directly into
> the core executable. I doubt anyone will be interested in taking on
> the task of supporting a parallel all-static build.
>
> I think this means we can write off VAX on NetBSD/OpenBSD as a viable
> platform for Postgres :-(. I'm sad to hear it, but certainly have
> not got the cycles personally to prevent it.
>
OpenBSD/vax is static only. NetBSD/vax has dynamic libraries.

-- Ragge

[Matt Thomas]

On Jun 24, 2014, at 9:42 AM, Tom Lane <***@sss.pgh.pa.us> wrote:

> I think this means we can write off VAX on NetBSD/OpenBSD as a viable
> platform for Postgres :-(. I'm sad to hear it, but certainly have
> not got the cycles personally to prevent it.

Why? NetBSD/vax has supported shared libraries for a long long time.

[Paul Koning]

On Jun 24, 2014, at 12:42 PM, Tom Lane <***@sss.pgh.pa.us> wrote:

> "Sebastian Reitenbach" <***@l00-bugdead-prods.de> writes:
>> OK, that was easy:
>
>> $ cd /usr/ports/databases/postgresql
>> $ make install
>> ===> postgresql-client-9.3.4p0 requires shared libraries .
>
>> OpenBSD VAX is static only, so no postgresql on OpenBSD
>> VAX before shared libraries will ever be made working on it.
>
> Ouch. We long ago passed the point of no return as far as requiring
> shared library support: there's too much backend functionality that's
> in separate shared libraries rather than being linked directly into
> the core executable. I doubt anyone will be interested in taking on
> the task of supporting a parallel all-static build.
>
> I think this means we can write off VAX on NetBSD/OpenBSD as a viable
> platform for Postgres :-(. I'm sad to hear it, but certainly have
> not got the cycles personally to prevent it.

NetBSD and OpenBSD are different systems. I don’t remember if NetBSD supports shared libraries on VAX, but that’s independent of the fact that OpenBSD doesn’t.

paul

[David Brownlee]

Well the latest NetBSD/vax package build doesn't seem to include any
PostgreSQL packages
http://ftp.netbsd.org/pub/pkgsrc/packages/NetBSD/vax/6.0_2014Q1/ but I
don't know why.

I'll try a quick (hah :) build this end to see what happens

David



On 24 June 2014 02:12, Robert Haas <***@gmail.com> wrote:

> On Mon, Jun 23, 2014 at 6:58 PM, Greg Stark <***@mit.edu> wrote:
> > On Mon, Jun 23, 2014 at 3:09 PM, Robert Haas <***@gmail.com>
> wrote:
> >> However, we don't know of anyone who has tried to do this in a very
> >> long time, and are therefore considering removing the remaining
> >> support for the VAX platform. Has anyone tried to build PostgreSQL
> >> for VAX lately?
> >
> > Actually I tried a while ago but got stuck configuring the network on
> > simh so I could get all the tools. I can try again if there's interest
> > but we don't necessarily need to keep a port just because there's a
> > simulator for it.
>
> That's really up to you. I'm not particularly interested in
> generating interest in maintaining this port if there wouldn't
> otherwise be any; I'm trying to figure out whether there is existing
> interest in it. For all I know, <whatever>BSD is shipping PostgreSQL
> binaries for VAX and every other platform they support in each new
> release and people are using them to get real work done. Then again,
> for all I know, it doesn't even compile on that platform, and if you
> did manage to get it to compile it wouldn't fit on the disk, and if
> you managed to fit it on the disk it wouldn't work because key system
> calls aren't supported. If someone is still interested in this, I'm
> hoping they'll help us figure out whether it's anywhere close to
> working, and maybe even contribute a buildfarm critter. If no one
> cares, then let's just rip it out and be done with it.
>
> --
> Robert Haas
> EnterpriseDB: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company

[Robert Haas]

On Tue, Jun 24, 2014 at 10:16 PM, John Klos <***@ziaspace.com> wrote:
>> Has anyone tried to build PostgreSQL for VAX lately? If so, did it
>> compile? Did you have to use --disable-spinlocks to get it to compile? If
>> it did compile, can you actually run it, and does it pass the regression
>> tests and work as expected? Would you be willing to work with the
>> PostgreSQL to ensure continuing support for this platform, or does that seem
>> not worthwhile for whatever reason?
>
> I've compiled postgresql93-client and postgresql93-server from pkgsrc on a
> VAX running NetBSD 6.1.4. The initial launch didn't like the default stack
> limit:
>
> /etc/rc.d/pgsql start
> Initializing PostgreSQL databases.
> LOG: invalid value for parameter "max_stack_depth": 100
> DETAIL: "max_stack_depth" must not exceed 0kB.
> HINT: Increase the platform's stack depth limit via "ulimit -s" or local
> equivalent.
> FATAL: failed to initialize max_stack_depth to 100
> child process exited with exit code 1
> initdb: removing data directory "/usr/local/pgsql/data"
> pg_ctl: database system initialization failed
>
> I unlimited and tried again. The pgsql process showed it was using 146
> megabytes of memory while initializing, then got as far as:
>
> /etc/rc.d/pgsql start
> Initializing PostgreSQL databases.

What value did it select for shared_buffers? How much memory does a
high-end VAX have? These days, we try to set shared_buffers = 128MB
if the platform will support it, but it's supposed to fall back to
smaller values if that doesn't work. It will try allocating that much
though, at least for a moment, to see whether it can.

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

[John Klos]

Hi,

> What value did it select for shared_buffers? How much memory does a
> high-end VAX have? These days, we try to set shared_buffers = 128MB
> if the platform will support it, but it's supposed to fall back to
> smaller values if that doesn't work. It will try allocating that much
> though, at least for a moment, to see whether it can.

A high end VAX, such as a 4000 Model 108, can have 512 megs (as can an
11/780, at least in theory), but most of the VAXen used here are
VAXstations such as the 4000/60 or 4000/90, 90a or 96, which have either
104 megs or 128 megs.

I was trying it just using the default postgresql.conf. I changed it:

< max_connections = 10 # (change requires restart)
> max_connections = 40 # (change requires restart)
< shared_buffers = 16MB # min 128kB
> shared_buffers = 128MB # min 128kB
< temp_buffers = 2MB # min 800kB
< max_prepared_transactions = 0 # zero disables the feature
> #temp_buffers = 8MB # min 800kB
> #max_prepared_transactions = 0 # zero disables the feature
< maintenance_work_mem = 8MB # min 1MB
< max_stack_depth = 1MB # min 100kB
> #maintenance_work_mem = 16MB # min 1MB
> #max_stack_depth = 2MB # min 100kB
< max_files_per_process = 100 # min 25
> #max_files_per_process = 1000 # min 25


and it launched fine. I then tried to run:

gmake MAX_CONNECTIONS=5 installcheck

in /usr/pkgsrc/databases/postgresql93-server/work/postgresql-9.3.4/src/test/regress,
but it failed with:

...
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'
failed
gmake: *** [submake-libpgport] Error 2

That's all I have time for tonight. Is there an easier way to run a
testsuite?

Thanks,
John

[Robert Haas]

On Wed, Jun 25, 2014 at 5:30 AM, John Klos <***@ziaspace.com> wrote:
> A high end VAX, such as a 4000 Model 108, can have 512 megs (as can an
> 11/780, at least in theory), but most of the VAXen used here are VAXstations
> such as the 4000/60 or 4000/90, 90a or 96, which have either 104 megs or 128
> megs.

Hmm, not bad for old hardware.

> and it launched fine. I then tried to run:
>
> gmake MAX_CONNECTIONS=5 installcheck
>
> in
> /usr/pkgsrc/databases/postgresql93-server/work/postgresql-9.3.4/src/test/regress,
> but it failed with:
>
> ...
> 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'
> failed
> gmake: *** [submake-libpgport] Error 2
>
> That's all I have time for tonight. Is there an easier way to run a
> testsuite?

I think you're doing it right, but apparently configure is
mis-identifying which flags are needed for thread-safety on your
platform. It's possible configuring with --disable-thread-safety
would help, or you could manually edit the Makefile.

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.

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

[John Klos]

>> That's all I have time for tonight. Is there an easier way to run a
>> testsuite?
>
> I think you're doing it right, but apparently configure is
> mis-identifying which flags are needed for thread-safety on your
> platform. It's possible configuring with --disable-thread-safety
> would help, or you could manually edit the Makefile.

I'll play with it some more in a little bit. This is why I tend to trust
the pkgsrc framework - it just works.

> 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.

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.

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.

Thanks,
John

[Robert Haas]

On Wed, Jun 25, 2014 at 1:05 PM, John Klos <***@ziaspace.com> 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

[Greg Stark]

On Wed, Jun 25, 2014 at 10:17 AM, Robert Haas <***@gmail.com> 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.

Yeah it seems to me that these kinds of autoconf and initdb tests
failing are different from a platform where the spinlock code doesn't
work. It's actually valuable to have a platform where people routinely
trigger those configuration values. If they're broken there's not much
value in carrying them.


--
greg

[Thor Lancelot Simon]

On Wed, Jun 25, 2014 at 10:50:47AM -0700, Greg Stark wrote:
> On Wed, Jun 25, 2014 at 10:17 AM, Robert Haas <***@gmail.com> 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.
>
> Yeah it seems to me that these kinds of autoconf and initdb tests
> failing are different from a platform where the spinlock code doesn't
> work. It's actually valuable to have a platform where people routinely
> trigger those configuration values. If they're broken there's not much
> value in carrying them.

Well, I have to ask this question: why should there be any "vax-specific
code"? What facilities beyond what POSIX with the threading extensions
offers on a modern system do you really need? Why?

It seems to me that NetBSD/vax is a very good platform for testing one's
assumptions about whether one's code is truly portable -- because it is
a moderately weird architecture, with some resource constraints, but with
a modern kernel and runtime offering everything you'd get from a software
point of view on any other platform.

Except, of course, for IEEE floating point, because the VAX's floating point
unit simply does not provide that. But if other tests fail on the VAX or
one's source tree is littered with any other kind of VAX-specific code or
special cases for VAX, I would submit that this suggests one's code has
fairly serious architectual or implementation discipline issues.

Thor

[Robert Haas]

On Wed, Jul 16, 2014 at 11:45 PM, Thor Lancelot Simon <***@panix.com> wrote:
> Well, I have to ask this question: why should there be any "vax-specific
> code"? What facilities beyond what POSIX with the threading extensions
> offers on a modern system do you really need? Why?

We have a spinlock implementation. When spinlocks are not available,
we have to fall back to using semaphores, which is much slower.

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

[Thor Lancelot Simon]

On Thu, Jul 17, 2014 at 07:47:28AM -0400, Robert Haas wrote:
> On Wed, Jul 16, 2014 at 11:45 PM, Thor Lancelot Simon <***@panix.com> wrote:
> > Well, I have to ask this question: why should there be any "vax-specific
> > code"? What facilities beyond what POSIX with the threading extensions
> > offers on a modern system do you really need? Why?
>
> We have a spinlock implementation. When spinlocks are not available,
> we have to fall back to using semaphores, which is much slower.

Neither pthread_mutex nor pthread_rwlock suffices?

Is the spinlock implementation in terms of the primitives provided by
atomic.h? Could it be? If so there should really be nothing unusual
about the VAX platform except the FPU.

Thor

[Greg Stark]

On Thu, Jul 17, 2014 at 4:45 AM, Thor Lancelot Simon <***@panix.com> wrote:
> Except, of course, for IEEE floating point, because the VAX's floating point
> unit simply does not provide that

Actually I think that's relevant. We usually get focused on the
concurrency because that's an area where architectures vary a lot but
it sounds like VAX barely supports multiple CPUs and generally older
architectures had fairly mundane concurrency semantics since they were
designed to work with existing toolchains. From memory it wasn't until
later Sparc chips and Alpha that people started to experiment with
looser concurrency models and expecting the toolchains to satisfy
complex constraints to make them work.

But imho the interesting thing about supporting some older
architectures is for things like smoking out assumptions that math is
IEEE floating point or whatever caused initdb to generate an initial
config that couldn't start due to requiring too much memory.

There could also be interesting(ish) performance losses if we're using
lots of floating point math on a machine where floating point is
emulated or perhaps using lots of 64-bit integers on a machine where
it's implemented by the compiler using 32-bit operations. I don't
think we're too concerned about performance on older architectures but
if it's easy enough to avoid we might want to. Or at least we might
want to know what architectures can't reasonably run a database due to
these kinds of issues.





--
greg

[Johnny Billquist]

On 2014-07-17 16:53, Greg Stark wrote:
> On Thu, Jul 17, 2014 at 4:45 AM, Thor Lancelot Simon <***@panix.com> wrote:
>> Except, of course, for IEEE floating point, because the VAX's floating point
>> unit simply does not provide that
>
> Actually I think that's relevant. We usually get focused on the
> concurrency because that's an area where architectures vary a lot but
> it sounds like VAX barely supports multiple CPUs and generally older
> architectures had fairly mundane concurrency semantics since they were
> designed to work with existing toolchains. From memory it wasn't until
> later Sparc chips and Alpha that people started to experiment with
> looser concurrency models and expecting the toolchains to satisfy
> complex constraints to make them work.

Well, VAXen support multiple CPUs just fine. However, NetBSD/vax barely
have support for it. That could of course change with time, as there are
plenty of multiple CPU machines around. We just need to add support for
them in NetBSD...

Also, VAX did not use CAS as the general paradigm for atomic writes and
so on, but have other explicit instructions that are guaranteed to be
atomic. NetBSD/vax don't use the VAX specific instructions, but emulates
CAS in the kernel instead. But I don't remember how that extends to
userland. It's obviously easiest if userland programs use the pthread
library functions, which are guaranteed to work right even in
multiprocessor environment.

Implementing your own spinlocks is of course possible, but a horrible
way to use machine resources in userland.

Johnny

--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: ***@softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol

[Greg Stark]

On Thu, Jul 17, 2014 at 4:04 PM, Johnny Billquist <***@update.uu.se> wrote:
> Also, VAX did not use CAS as the general paradigm for atomic writes and so
> on, but have other explicit instructions that are guaranteed to be atomic.
> NetBSD/vax don't use the VAX specific instructions, but emulates CAS in the
> kernel instead. But I don't remember how that extends to userland. It's
> obviously easiest if userland programs use the pthread library functions,
> which are guaranteed to work right even in multiprocessor environment.

pthread functions may work by accident in shared memory but there's no
way to be sure they won't depend on some pthread threading data
structures. In short, if you don't use pthreads you can't really count
on pthread functions to work.

We did experiment a while back with using futexes on Linux instead of
our spinlocks but the experiments didn't seem to work out.

--
greg

[Tom Lane]

Robert Haas <***@gmail.com> writes:
> On Wed, Jun 25, 2014 at 1:05 PM, John Klos <***@ziaspace.com> 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

[Dave McGuire]

On 06/25/2014 01:57 PM, Tom Lane wrote:
> Robert Haas <***@gmail.com> writes:
>> On Wed, Jun 25, 2014 at 1:05 PM, John Klos <***@ziaspace.com> 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

[Tom Lane]

Dave McGuire <***@neurotica.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.

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

[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

[Andres Freund]

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


--
Sent via pgsql-hackers mailing list (pgsql-***@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[Tom Lane]

Andres Freund <***@2ndquadrant.com> 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

[Dave McGuire]

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

[Tom Lane]

Dave McGuire <***@neurotica.com> 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

[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

[Andres Freund]

On June 29, 2014 9:01:27 PM CEST, Dave McGuire <***@neurotica.com> 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

[Dave McGuire]

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

[Johnny Billquist]

On 2014-06-29 12:12, Dave McGuire 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? ;))

Well, VAX-11/78x do not support SMP, they have (had) ASMP only.

Johnny

[Patrick Finnegan]

On Sun, Jun 29, 2014 at 3:12 PM, Dave McGuire <***@neurotica.com> 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

[Anders Magnusson]

Dave McGuire skrev 2014-06-29 21:01:
> 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?
>
I made it run on 8300 once, in the early days of NetBSD MP. I planned
to make it run on both 8800 and 6300, but due to lack of docs neither of
those came true.
So, unless someone has a 8300 to test on (just over 1 VUPS per CPU, not
much), current state is unknown. "It worked last time I tested" :-)

-- Ragge

[Patrick Finnegan]

On Sun, Jun 29, 2014 at 3:01 PM, Dave McGuire <***@neurotica.com> 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

[Dave McGuire]

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

[John Klos]

> 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

[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 <***@sss.pgh.pa.us> wrote:

> Dave McGuire <***@neurotica.com> 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

[Dave McGuire]

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

[John Klos]

> 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

[Robert Haas]

On Wed, Jun 25, 2014 at 1:58 PM, John Klos <***@ziaspace.com> 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

[Dave McGuire]

On 06/25/2014 05:30 AM, John Klos wrote:
>> What value did it select for shared_buffers? How much memory does a
>> high-end VAX have? These days, we try to set shared_buffers = 128MB
>> if the platform will support it, but it's supposed to fall back to
>> smaller values if that doesn't work. It will try allocating that much
>> though, at least for a moment, to see whether it can.
>
> A high end VAX, such as a 4000 Model 108, can have 512 megs (as can an
> 11/780, at least in theory), but most of the VAXen used here are
> VAXstations such as the 4000/60 or 4000/90, 90a or 96, which have either
> 104 megs or 128 megs.

My VAX-7000 has 1.5GB. B-)

-Dave

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

[Dave McGuire]

On 06/25/2014 11:23 AM, ***@e-bbes.com wrote:
> Zitat von Dave McGuire <***@neurotica.com>:
>
>>> A high end VAX, such as a 4000 Model 108, can have 512 megs (as can an
>>> 11/780, at least in theory), but most of the VAXen used here are
>>> VAXstations such as the 4000/60 or 4000/90, 90a or 96, which have either
>>> 104 megs or 128 megs.
>>
>> My VAX-7000 has 1.5GB. B-)
>
> To busy to upgrade to the full, or saving power?
> ;-)

A bit of both. ;)

-Dave

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

[e***@e-bbes.com]

Zitat von Dave McGuire <***@neurotica.com>:

>> A high end VAX, such as a 4000 Model 108, can have 512 megs (as can an
>> 11/780, at least in theory), but most of the VAXen used here are
>> VAXstations such as the 4000/60 or 4000/90, 90a or 96, which have either
>> 104 megs or 128 megs.
>
> My VAX-7000 has 1.5GB. B-)

To busy to upgrade to the full, or saving power?
;-)

[John Klos]

Hi,

> Has anyone tried to build PostgreSQL for VAX lately? If so, did it
> compile? Did you have to use --disable-spinlocks to get it to compile?
> If it did compile, can you actually run it, and does it pass the
> regression tests and work as expected? Would you be willing to work
> with the PostgreSQL to ensure continuing support for this platform, or
> does that seem not worthwhile for whatever reason?

I've compiled postgresql93-client and postgresql93-server from pkgsrc on a
VAX running NetBSD 6.1.4. The initial launch didn't like the default stack
limit:

/etc/rc.d/pgsql start
Initializing PostgreSQL databases.
LOG: invalid value for parameter "max_stack_depth": 100
DETAIL: "max_stack_depth" must not exceed 0kB.
HINT: Increase the platform's stack depth limit via "ulimit -s" or local
equivalent.
FATAL: failed to initialize max_stack_depth to 100
child process exited with exit code 1
initdb: removing data directory "/usr/local/pgsql/data"
pg_ctl: database system initialization failed


I unlimited and tried again. The pgsql process showed it was using 146
megabytes of memory while initializing, then got as far as:

/etc/rc.d/pgsql start
Initializing PostgreSQL databases.

WARNING: enabling "trust" authentication for local connections
You can change this by editing pg_hba.conf or using the option -A, or
--auth-local and --auth-host, the next time you run initdb.
Starting pgsql.

Then the machine paniced. The serial console showed:

panic: usrptmap space leakage
cpu0: Begin traceback...
panic: usrptmap space leakage
Stack traceback :
Process is executing in user space.
cpu0: End traceback...

dump to dev 9,1 not possible


It does compile and initialize, so the VAX code does work. However,
considering how much memory it uses, I wonder how many people would
actually use it. I did run Apache / MySQL / PHP on a VAXstation 4000/60
not long ago, but MySQL takes way too much memory, too. Don't even get me
started on how memory PHP uses - someone has to write some good weblog
software in C one of these days...

John

[Toby Thain]

On 24/06/14 10:16 PM, John Klos wrote:
> Hi,
>
>> Has anyone tried to build PostgreSQL for VAX lately? If so, did it
>> compile? Did you have to use --disable-spinlocks to get it to
>> compile? If it did compile, can you actually run it, and does it pass
>> the regression tests and work as expected? Would you be willing to
>> work with the PostgreSQL to ensure continuing support for this
>> platform, or does that seem not worthwhile for whatever reason?
>
> I've compiled postgresql93-client and postgresql93-server from pkgsrc on
> a VAX running NetBSD 6.1.4. ...
> It does compile and initialize, so the VAX code does work. However,
> considering how much memory it uses, I wonder how many people would
> actually use it. I did run Apache / MySQL / PHP on a VAXstation 4000/60

I guess I shan't expect to run PgSQL on a MicroVAX II (9MB), NetBSD
1.4.1. I did get Apache 1.3.x built on it.

> not long ago, but MySQL takes way too much memory, too. Don't even get
> me started on how memory PHP uses - someone has to write some good
> weblog software in C one of these days...

If only C and PHP weren't the only options!

--T

>
> John
>

[David Brownlee]

On 25 June 2014 12:38, Toby Thain <***@telegraphics.com.au> wrote:
> On 24/06/14 10:16 PM, John Klos wrote:
>>
>> Hi,
>>
>>> Has anyone tried to build PostgreSQL for VAX lately? If so, did it
>>> compile? Did you have to use --disable-spinlocks to get it to
>>> compile? If it did compile, can you actually run it, and does it pass
>>> the regression tests and work as expected? Would you be willing to
>>> work with the PostgreSQL to ensure continuing support for this
>>> platform, or does that seem not worthwhile for whatever reason?
>>
>>
>> I've compiled postgresql93-client and postgresql93-server from pkgsrc on
>> a VAX running NetBSD 6.1.4. ...
>>
>> It does compile and initialize, so the VAX code does work. However,
>> considering how much memory it uses, I wonder how many people would
>> actually use it. I did run Apache / MySQL / PHP on a VAXstation 4000/60
>
> I guess I shan't expect to run PgSQL on a MicroVAX II (9MB), NetBSD 1.4.1. I
> did get Apache 1.3.x built on it.

I suspect it might technically be possible to run PgSQL on that
hardware - probably best done with an app on another box (maybe a
second uVAX II :) which is not in a particular hurry for query
responses

>> not long ago, but MySQL takes way too much memory, too. Don't even get
>> me started on how memory PHP uses - someone has to write some good
>> weblog software in C one of these days...
>
> If only C and PHP weren't the only options!

Tsk, how could we forget VAX MACRO assembler :-p

[Anders Magnusson]

John Klos skrev 2014-06-25 04:16:
> Then the machine paniced. The serial console showed:
>
> panic: usrptmap space leakage
> cpu0: Begin traceback...
> panic: usrptmap space leakage
> Stack traceback :
> Process is executing in user space.
> cpu0: End traceback...
>
Hm, can you add info about this panic to PR #28379 ? I will try to hunt
this down soon, so I need some test cases.

-- Ragge