For completeness, here's the regression tests from the conrttrib
modules. I haven't looked into why earthdistance is coming up with
such odd results but I suspect it all comes from the same arithmetic
source. I don't see any surprising internal dependencies on ieee
floating point.
For what it's
Greg Stark st...@mit.edu writes:
For completeness, here's the regression tests from the conrttrib
modules. I haven't looked into why earthdistance is coming up with
such odd results but I suspect it all comes from the same arithmetic
source. I don't see any surprising internal dependencies on
I wrote:
Greg Stark st...@mit.edu writes:
For what it's worth there are a number of mentions in the docs of
platforms that have non-ieee semantics behaving differently so I
wouldn't say we don't support such platforms. If we could avoid the
test failures without weakening the tests for other
On Thu, Aug 20, 2015 at 04:32:19PM +0100, Greg Stark wrote:
That's the problem. initdb tests how many connections can start up
when writing the default config. But we assume that each process can
use up to the rlimit file descriptors without running into a
system-wide limit.
That sounds
Attached is the pg_regress diff. I believe they are all user-visible
effects of non-iee fp math though I would have expected the rounding
to work right and I'm not clear how gist ends up returning rows in a
different order.
There are still two local changes. The SIGILL handler which is set to
the
Greg Stark st...@mit.edu writes:
Attached is the pg_regress diff. I believe they are all user-visible
effects of non-iee fp math though I would have expected the rounding
to work right and I'm not clear how gist ends up returning rows in a
different order.
I concur that these are generally
I wrote:
On further reflection, there seems little reason not to change it: it's
pretty silly to imagine that selectivity estimates produced via this
technique would have anything like 14 decimal places of precision anyhow.
I've done something about both this and the bipartite_match issue in
I wrote:
Oh, interesting. The largest possible value of base is 256, and the
code limits the amount of string it'll scan to 20 bytes, which means
denom could reach at most 256^21 = 3.7e50. Perfectly fine with
IEEE-math doubles, but not so much with other arithmetics.
We could hold the
I wrote:
I think we should replace the whole mess with, say, uint32 for float and
UINT_MAX for infinity. That will be more portable, probably faster, and
it will work correctly up to substantially *larger* peak distances than
the existing code.
After studying the logic a bit more, I realized
Greg Stark st...@mit.edu writes:
On 22 Aug 2015 18:02, Tom Lane t...@sss.pgh.pa.us wrote:
The hang is actually in the groupingset tests in
bipartite_match.c:hk_breadth_search().
Is it that function itself that's hanging, or is the problem that its
caller expects it to ultimately return true,
On Sun, Aug 23, 2015 at 8:18 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I've done something about both this and the bipartite_match issue in HEAD.
I'd be curious to see all the remaining regression differences on VAX.
I'll run a git pull overnight :)
--
greg
--
Sent via pgsql-hackers mailing
On 22 Aug 2015 18:02, Tom Lane t...@sss.pgh.pa.us wrote:
Why not define infnan() and make it do the same thing as
FloatExceptionHandler? Or was that what you meant?
That's exactly what I meant, instead of my quick hack to add a signal
handler for sigill.
The hang is actually in the
Greg Stark st...@mit.edu writes:
Hmm. The backtrace is here but I think it's lying about the specific line.
#0 convert_one_string_to_scalar (value=0x7f20e9a3 ,
rangelo=32, rangehi=122, 2132863395, 32, 122)
at selfuncs.c:3873
#1 0x00435880 in convert_string_to_scalar (
Greg Stark st...@mit.edu writes:
On Thu, Aug 20, 2015 at 3:29 PM, Tom Lane t...@sss.pgh.pa.us wrote:
That seems worth poking into.
Mea culpa. Not a planner crash but rather an overflow from exp(). It
turns out exp() and other math library functions on Vax do not signal
FPE but rather have a
[- the vax lists since they cause majordomo confirmation emails for
anyone responding]
On Thu, Aug 20, 2015 at 3:29 PM, Tom Lane t...@sss.pgh.pa.us wrote:
There are some planner tests that fail with floating point exceptions
-- that's probably a bug on our part. And I've seen at least one
On Wed, Jun 25, 2014 at 6:05 PM, John Klos j...@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
Greg Stark st...@mit.edu writes:
So I've been playing with this a bit. I have simh running on my home
server as a Vax 3900 with NetBSD 6.1.5. My home server was mainly
intended to be a SAN and its cpu is woefully underpowered so the
resulting VAX is actually very very slow. So slow I wonder
On Thu, Aug 20, 2015 at 4:13 PM, David Brownlee a...@absd.org wrote:
2) The initdb problem is actually not our fault. It looks like a
NetBSD kernel bug when allocating large shared memory blocks on a
machine without lots of memory. There's not much initdb can do with a
kernel panic...
That
On Thu, Aug 20, 2015 at 3:29 PM, Tom Lane t...@sss.pgh.pa.us wrote:
4) One of the tablesample tests seems to freeze indefinitely. I
haven't looked into why yet. That might indeed indicate that the
spinlock code isn't working?
The tablesample tests seem like a not-very-likely first place for
On 20 August 2015 at 14:54, Greg Stark st...@mit.edu wrote:
On Wed, Jun 25, 2014 at 6:05 PM, John Klos j...@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
On 2015-08-20 16:42:21 +0100, Greg Stark wrote:
Ah, I was wrong. It's not the tablesample test -- I think that was the
last one to complete. Annoyingly we don't seem to print test names
until they finish.
It was groupingsets. And it's stuck again on the same query:
regression=# select
On Wed, Jul 16, 2014 at 11:45 PM, Thor Lancelot Simon t...@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
On Thu, Jul 17, 2014 at 4:45 AM, Thor Lancelot Simon t...@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
On Thu, Jul 17, 2014 at 4:04 PM, Johnny Billquist b...@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
On Wed, Jun 25, 2014 at 10:50:47AM -0700, Greg Stark wrote:
On Wed, Jun 25, 2014 at 10:17 AM, Robert Haas robertmh...@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
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 t...@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
On 2014-07-17 16:53, Greg Stark wrote:
On Thu, Jul 17, 2014 at 4:45 AM, Thor Lancelot Simon t...@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
On 6/29/14, 12:20 PM, Tom Lane wrote:
I'm tempted to just rip out all the useless code rather than fix the
logic bug as such. OTOH, that might complicate updating to more recent
versions of the original Autoconf macro. On the third hand, we've not
bothered to do that in ten years either.
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
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
On Sun, Jun 29, 2014 at 10:24:22AM -0400, Tom Lane wrote:
http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=coypudt=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
On 06/29/2014 03:35 PM, Tom Lane wrote:
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-)
There were so many PDP-11s around CMU when I was an undergrad that
I remember seeing spare ones being used as
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
On 06/25/2014 01:57 PM, Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
On Wed, Jun 25, 2014 at 1:05 PM, John Klos j...@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
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
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
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
On Sun, Jun 29, 2014 at 3:12 PM, Dave McGuire mcgu...@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
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.
On Sun, Jun 29, 2014 at 3:01 PM, Dave McGuire mcgu...@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,
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 t...@sss.pgh.pa.us wrote:
Dave McGuire mcgu...@neurotica.com writes:
On 06/29/2014 10:54 AM,
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
Dave McGuire mcgu...@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
On 2014-06-29 10:24:22 -0400, Tom Lane wrote:
Dave McGuire mcgu...@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
Andres Freund and...@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
[ trimming the cc list since this isn't VAX-specific ]
I wrote:
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
I wrote:
BTW, it sure looks like the part of ACX_PTHREAD beginning with
# Various other checks:
if test x$acx_pthread_ok = xyes; then
(lines 163..210 in HEAD's acx_pthread.m4) is dead code.
On closer inspection, this has been broken since commit
On 2014-06-29 12:20:02 -0400, Tom Lane wrote:
I wrote:
BTW, it sure looks like the part of ACX_PTHREAD beginning with
# Various other checks:
if test x$acx_pthread_ok = xyes; then
(lines 163..210 in HEAD's acx_pthread.m4) is dead code.
On closer inspection, this has been
Dave McGuire mcgu...@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
On June 29, 2014 9:01:27 PM CEST, Dave McGuire mcgu...@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
Dave McGuire mcgu...@neurotica.com writes:
On 06/29/2014 10:24 AM, Tom Lane wrote:
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-)
There were so many PDP-11s around CMU when I was an undergrad that
I
On Wed, Jun 25, 2014 at 5:30 AM, John Klos j...@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
On Wed, Jun 25, 2014 at 1:05 PM, John Klos j...@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
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
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
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
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
On 25 June 2014 12:38, Toby Thain t...@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
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
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
On Wed, Jun 25, 2014 at 10:17 AM, Robert Haas robertmh...@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
Robert Haas robertmh...@gmail.com writes:
On Wed, Jun 25, 2014 at 1:05 PM, John Klos j...@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
On Wed, Jun 25, 2014 at 1:58 PM, John Klos j...@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
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
On Tue, Jun 24, 2014 at 7:45 AM, Sebastian Reitenbach
sebas...@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
On 06/23/2014 06:58 PM, Greg Stark wrote:
On Mon, Jun 23, 2014 at 3:09 PM, Robert Haas robertmh...@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
On Tuesday, June 24, 2014 03:12 CEST, Robert Haas robertmh...@gmail.com wrote:
On Mon, Jun 23, 2014 at 6:58 PM, Greg Stark st...@mit.edu wrote:
On Mon, Jun 23, 2014 at 3:09 PM, Robert Haas robertmh...@gmail.com wrote:
However, we don't know of anyone who has tried to do this in a very
On Tuesday, June 24, 2014 13:37 CEST, Sebastian Reitenbach
sebas...@l00-bugdead-prods.de wrote:
On Tuesday, June 24, 2014 03:12 CEST, Robert Haas robertmh...@gmail.com
wrote:
On Mon, Jun 23, 2014 at 6:58 PM, Greg Stark st...@mit.edu wrote:
On Mon, Jun 23, 2014 at 3:09 PM, Robert Haas
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
Sebastian Reitenbach sebas...@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
Dave McGuire mcgu...@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
Tom Lane skrev 2014-06-24 18:42:
Sebastian Reitenbach sebas...@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
On Jun 24, 2014, at 9:42 AM, Tom Lane t...@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
On Jun 24, 2014, at 12:42 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Sebastian Reitenbach sebas...@l00-bugdead-prods.de writes:
OK, that was easy:
$ cd /usr/ports/databases/postgresql
$ make install
=== postgresql-client-9.3.4p0 requires shared libraries .
On 06/24/2014 12:42 PM, Tom Lane wrote:
Sebastian Reitenbach sebas...@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
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
On Tue, Jun 24, 2014 at 10:16 PM, John Klos j...@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
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,
On Mon, Jun 23, 2014 at 3:09 PM, Robert Haas robertmh...@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?
On Mon, Jun 23, 2014 at 6:58 PM, Greg Stark st...@mit.edu wrote:
On Mon, Jun 23, 2014 at 3:09 PM, Robert Haas robertmh...@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
80 matches
Mail list logo
