I wrote:
> Greg Stark 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 platf
Greg Stark 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 ieee
> flo
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 wo
Greg Stark 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 unsurprising
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
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
On Sun, Aug 23, 2015 at 8:18 PM, Tom Lane 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 list (pgsql-hac
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
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 reali
Greg Stark writes:
> On 22 Aug 2015 18:02, "Tom Lane" 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, and it never does?
Greg Stark 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 (
> value=0x7f20
On 22 Aug 2015 18:02, "Tom Lane" 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 groupingset tests i
Greg Stark writes:
> On Thu, Aug 20, 2015 at 3:29 PM, Tom Lane 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 curious api that lets us c
[- the vax lists since they cause majordomo confirmation emails for
anyone responding]
On Thu, Aug 20, 2015 at 3:29 PM, Tom Lane 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
>> server crash (m
On 20 August 2015 at 14:54, Greg Stark wrote:
> On Wed, Jun 25, 2014 at 6:05 PM, John Klos 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, i
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=# sele
On Thu, Aug 20, 2015 at 3:29 PM, Tom Lane 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 such a
> t
On Thu, Aug 20, 2015 at 4:13 PM, David Brownlee 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 shoul
Greg Stark 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 if there's
On Wed, Jun 25, 2014 at 6:05 PM, John Klos 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, albei
On 2014-07-17 16:53, Greg Stark wrote:
On Thu, Jul 17, 2014 at 4:45 AM, Thor Lancelot Simon 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
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 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 moder
On Wed, Jun 25, 2014 at 10:50:47AM -0700, Greg Stark wrote:
> On Wed, Jun 25, 2014 at 10:17 AM, Robert Haas 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.
>
> Yea
On Thu, Jul 17, 2014 at 4:04 PM, Johnny Billquist 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
On Thu, Jul 17, 2014 at 4:45 AM, Thor Lancelot Simon 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 var
On Wed, Jul 16, 2014 at 11:45 PM, Thor Lancelot Simon 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
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 accur
On 06/25/2014 01:57 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, Jun 25, 2014 at 1:05 PM, John Klos 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 br
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
ma
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 u
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
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
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 VAX
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.
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 l
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 wrote:
> Dave McGuire writes:
> > On 06/29/2014 10:54 AM, Andres Freund wrote:
> >> Maybe I'm j
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.
N
On Sun, Jun 29, 2014 at 3:01 PM, Dave McGuire 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
On Sun, Jun 29, 2014 at 3:12 PM, 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 o
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
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, s
Dave McGuire 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 remember seeing spare
On June 29, 2014 9:01:27 PM CEST, Dave McGuire 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 yo
Dave McGuire 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 VAXe
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 h
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
e48322a6d6cfce1ec52ab303441df329
[ 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 test-for
Andres Freund 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
On 2014-06-29 10:24:22 -0400, Tom Lane wrote:
> Dave McGuire 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
> >
Dave McGuire 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 h
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 co
On Wed, Jun 25, 2014 at 1:58 PM, John Klos 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
> p
Robert Haas writes:
> On Wed, Jun 25, 2014 at 1:05 PM, John Klos 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, i
On Wed, Jun 25, 2014 at 10:17 AM, Robert Haas 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 a
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 ma
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
On 25 June 2014 12:38, Toby Thain 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 doe
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 y
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
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 Postgr
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
On Wed, Jun 25, 2014 at 1:05 PM, John Klos 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
On Wed, Jun 25, 2014 at 5:30 AM, John Klos 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
On Tue, Jun 24, 2014 at 10:16 PM, John Klos 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 e
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
On 06/24/2014 12:42 PM, Tom Lane wrote:
> "Sebastian Reitenbach" 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 pos
On Jun 24, 2014, at 12:42 PM, Tom Lane wrote:
> "Sebastian Reitenbach" 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,
On Jun 24, 2014, at 9:42 AM, 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.
Why? NetBSD/vax has supported shared libraries for a long lon
Tom Lane skrev 2014-06-24 18:42:
"Sebastian Reitenbach" 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 ma
Dave McGuire 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 libr
"Sebastian Reitenbach" 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 wi
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 wrote:
> On Mon
On Tuesday, June 24, 2014 13:37 CEST, "Sebastian Reitenbach"
wrote:
> On Tuesday, June 24, 2014 03:12 CEST, Robert Haas
> wrote:
>
> > On Mon, Jun 23, 2014 at 6:58 PM, Greg Stark wrote:
> > > On Mon, Jun 23, 2014 at 3:09 PM, Robert Haas
> > > wrote:
> > >> However, we don't know of anyone
On Tuesday, June 24, 2014 03:12 CEST, Robert Haas wrote:
> On Mon, Jun 23, 2014 at 6:58 PM, Greg Stark wrote:
> > On Mon, Jun 23, 2014 at 3:09 PM, Robert Haas wrote:
> >> However, we don't know of anyone who has tried to do this in a very
> >> long time, and are therefore considering removing
On 06/23/2014 06:58 PM, Greg Stark wrote:
> On Mon, Jun 23, 2014 at 3:09 PM, Robert Haas 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 Post
On Tue, Jun 24, 2014 at 7:45 AM, Sebastian Reitenbach
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
On Mon, Jun 23, 2014 at 6:58 PM, Greg Stark wrote:
> On Mon, Jun 23, 2014 at 3:09 PM, Robert Haas 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
On Mon, Jun 23, 2014 at 3:09 PM, Robert Haas 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 wh
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, w
80 matches
Mail list logo
