Обсуждение: AIX support - alignment issues
Hi,
(sorry for sending this twice to you Noah, forgot -hackers the first time
round)
We've had a bunch of changes to manually deal with our alignment code not
understanding AIX alignment.
commit f3b421da5f4addc95812b9db05a24972b8fd9739
Author: Peter Eisentraut <peter_e@gmx.net>
Date: 2016-12-21 12:00:00 -0500
Reorder pg_sequence columns to avoid alignment issue
commit 79b716cfb7a1be2a61ebb4418099db1258f35e30
Author: Amit Kapila <akapila@postgresql.org>
Date: 2022-04-07 09:39:25 +0530
Reorder subskiplsn in pg_subscription to avoid alignment issues.
A good explanation of the problem is in https://postgr.es/m/20220402081346.GD3719101%40rfd.leadboat.com
I strikes me as a remarkably bad idea to manually try to maintain the correct
alignment. Even with the tests added it's still quite manual and requires
contorted struct layouts (see e.g. [1]).
I think we should either teach our system the correct alignment rules or we
should drop AIX support.
If we decide we want to continue supporting AIX we should bite the bullet and
add a 64bit-int TYPALIGN_*. It might be worth to translate that to bytes when
building tupledescs, so we don't need more branches (reducing them compared to
today).
Personally I think we should just drop AIX. The amount of effort to keep it
working is substantial due to being quite different from other unices ([2]), the is
very outdated, the whole ecosystem is barely on lifesupport ([3]). And all of that
for very little real world use.
Afaics we don't have access to an up2date AIX system. Some of have access to
7.2 via the gcc compile farm, but not 7.3. Most other niche-y operating
systems we can start in a VM, but I've yet to see a legal and affordable way
to do that with AIX.
I think Noah has done quite a heroic effort at keeping the AIX animals in a
kind-of-healthy state, but without more widespread access and more widespread
usage it seems like a doomed effort.
Greetings,
Andres Freund
[1] https://www.postgresql.org/message-id/CAFiTN-uiAngcW50Trwa94F1EWY2BxEx%2BB38QSyX3DtV3dzEGhA%40mail.gmail.com
[2] linking etc is handled entirely different, so there's a fair bit of
dedicated AIX code around the buildsystem - a lot of it vestigial stuff,
see references to aix3.2.5 etc.
[3] 7.2 was released in 2015-10-05, 7.3 in 2021-12-10, the set of changes is
pretty darn small for that timeframe
https://www.ibm.com/common/ssi/cgi-bin/ssialias?infotype=AN&subtype=CA&htmlfid=897/ENUS221-328&appname=USN
Bull / Atos stopped their AIX work in 2022-03-01 - unfortunately they
didn't even keep the announcement of that online.
https://www.linkedin.com/pulse/said-say-bull-closing-down-aix-open-source-platform-michaelis
https://github.com/power-devops/bullfreeware
On Sat, Jul 2, 2022 at 11:34 AM Andres Freund <andres@anarazel.de> wrote: > Personally I think we should just drop AIX. The amount of effort to keep it > working is substantial due to being quite different from other unices ([2]), the is > very outdated, the whole ecosystem is barely on lifesupport ([3]). And all of that > for very little real world use. I tend to agree about dropping AIX. But I wonder if there is an argument against that proposal that doesn't rely on AIX being relevant to at least one user. Has supporting AIX ever led to the discovery of a bug that didn't just affect AIX? In other words, are AIX systems peculiar in some particular way that clearly makes them more likely to flush out a certain class of bugs? What is the best argument *against* desupporting AIX that you know of? Desupporting AIX doesn't mean that any AIX users will be left in the lurch immediately. Obviously these users will be able to use a supported version of Postgres for several more years. -- Peter Geoghegan
Peter Geoghegan <pg@bowt.ie> writes:
> I tend to agree about dropping AIX. But I wonder if there is an
> argument against that proposal that doesn't rely on AIX being relevant
> to at least one user. Has supporting AIX ever led to the discovery of
> a bug that didn't just affect AIX?
Searching the commit log quickly finds
591e088dd
datetime.c's parsing logic has assumed that strtod() will accept
a string that looks like ".", which it does in glibc, but not on
some less-common platforms such as AIX.
glibc's behavior is clearly not meeting the letter of the POSIX spec here.
a745b9365
I'm not sure how we've managed not to notice this problem, but it
seems to explain slow execution of the 017_shm.pl test script on AIX
since commit 4fdbf9af5, which added a speculative "pg_ctl stop" with
the idea of making real sure that the postmaster isn't there. In the
test steps that kill-9 and then restart the postmaster, it's possible
to get past the initial signal attempt before kill() stops working
for the doomed postmaster. If that happens, pg_ctl waited till
PGCTLTIMEOUT before giving up ... and the buildfarm's AIX members
have that set very high.
Admittedly, this one is more about "slow" than about "AIX".
57b5a9646
Most versions of tar are willing to overlook the missing terminator, but
the AIX buildfarm animals were not. Fix by inventing a new kind of
bbstreamer that just blindly adds a terminator, and using it whenever we
don't parse the tar archive.
Another place where we failed to conform to relevant standards.
b9b610577
Fix ancient violation of zlib's API spec.
And another.
Now, it's certainly possible that AIX is the only surviving platform
that hasn't adopted bug-compatible-with-glibc interpretations of
POSIX. But I think the standard is the standard, and we ought to
stay within it. So I find value in these fixes.
regards, tom lane
Hi, On 2022-07-02 11:54:16 -0700, Peter Geoghegan wrote: > I tend to agree about dropping AIX. But I wonder if there is an > argument against that proposal that doesn't rely on AIX being relevant > to at least one user. Has supporting AIX ever led to the discovery of > a bug that didn't just affect AIX? Yes, it clearly has. But I tend to think that that's far outweighed by the complications triggered by AIX support. It'd be a different story if AIX hadn't a very peculiar linking model and was more widely accessible. > What is the best argument *against* desupporting AIX that you know of? Hm. - a distinct set of system libraries that can help find portability issues - With IBM's compiler it adds a, not otherwise used, compiler that PG builds with. So the warnings could theoretically help find issues that we wouldn't otherwise see - but I don't think that's been particularly useful (nor monitored). And the compiler is buggy enough to add a fair bit work over the years. > Desupporting AIX doesn't mean that any AIX users will be left in the > lurch immediately. Obviously these users will be able to use a > supported version of Postgres for several more years. Right. Greetings, Andres Freund
On Sat, Jul 2, 2022 at 12:22 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > Now, it's certainly possible that AIX is the only surviving platform > that hasn't adopted bug-compatible-with-glibc interpretations of > POSIX. But I think the standard is the standard, and we ought to > stay within it. So I find value in these fixes. I imagine that there is strong evolutionary pressure pushing minority platforms in the direction of bug-compatible-with-glibc. There is definitely a similar trend around things like endianness and alignment pickiness. But it wasn't always so. It seems fair to wonder if AIX bucks the glibc-compatible trend because it is already on the verge of extinction. If it wasn't just about dead already then somebody would have gone to the trouble of making it bug-compatible-with-glibc by now. (To be clear, I'm not arguing that this is a good thing.) Maybe it is still worth hanging on to AIX support for the time being, but it would be nice to have some idea of where we *will* finally draw the line. If the complaints from Andres aren't a good enough reason now, then what other hypothetical reasons might be good enough in the future? It seems fairly likely that Postgres desupporting AIX will happen (say) at some time in the next decade, no matter what happens today. -- Peter Geoghegan
Peter Geoghegan <pg@bowt.ie> writes:
> Maybe it is still worth hanging on to AIX support for the time being,
> but it would be nice to have some idea of where we *will* finally draw
> the line. If the complaints from Andres aren't a good enough reason
> now, then what other hypothetical reasons might be good enough in the
> future? It seems fairly likely that Postgres desupporting AIX will
> happen (say) at some time in the next decade, no matter what happens
> today.
Agreed. But I think that this sort of thing is better driven by
"when there's no longer anyone willing to do the legwork" than
by project policy. IOW, we'll stop when Noah gets tired of doing
it (and no one steps up to take his place).
In the case at hand, given that the test added by 79b716cfb/c1da0acbb
correctly detects troublesome catalog layouts (and no I've not studied
it myself), I don't see that we have to do more right now.
I am a little concerned though that we don't have access to the latest
version of AIX --- that seems like a non-maintainable situation.
regards, tom lane
Hi, On 2022-07-02 16:34:35 -0400, Tom Lane wrote: > Agreed. But I think that this sort of thing is better driven by > "when there's no longer anyone willing to do the legwork" than > by project policy. IOW, we'll stop when Noah gets tired of doing > it (and no one steps up to take his place). I do think we should take the impact it has on everyone into account, not just Noah's willingness. If it's just "does somebody still kind of maintain it" then we'll bear the distributed cost of complications for irrelevant platforms way longer than worthwhile. > In the case at hand, given that the test added by 79b716cfb/c1da0acbb > correctly detects troublesome catalog layouts (and no I've not studied > it myself), I don't see that we have to do more right now. What made me look at this issue right now is that the alignment issue lead the 56bit relfilenode patch to move the relfilenode field to the start of pg_class (ahead of the oid), because a 64bit value cannot be after a NameData. Now, I think we can do a bit better by moving a few more fields around. But the restriction still seems quite onerous. Greetings, Andres Freund
Andres Freund <andres@anarazel.de> writes:
> What made me look at this issue right now is that the alignment issue lead the
> 56bit relfilenode patch to move the relfilenode field to the start of pg_class
> (ahead of the oid),
Agreed, up with that we should not put. However ...
> because a 64bit value cannot be after a NameData.
... this coding rule strikes me as utterly ridiculous. Why can't we
instead insist that NAMEDATALEN must be a multiple of 8? Anyone who
tries to make it different from that is likely to be wasting padding
space even on platforms where there's not a deeper problem.
regards, tom lane
On Sun, Jul 3, 2022 at 8:34 AM Tom Lane <tgl@sss.pgh.pa.us> wrote: > I am a little concerned though that we don't have access to the latest > version of AIX --- that seems like a non-maintainable situation. The release history doesn't look toooo bad on that front: the live versions are 7.1 (2010-2023), 7.2 (2015-TBA) and 7.3 (2021-TBA). 7.3 only came out half a year ago, slightly after Windows 11, which we aren't testing yet either. Those GCC AIX systems seem to be provided by IBM and the Open Source Lab at Oregon State University which has a POWER lab providing ongoing CI services etc to various OSS projects, so I would assume that upgrades (and retirement of the about-to-be-desupported 7.1 system) will come along eventually. I don't have a dog in this race, but AIX is clearly not in the same category as HP-UX (and maybe Solaris is somewhere in between). AIX runs on hardware you can buy today that got a major refresh last year (Power 10), while HP-UX runs only on discontinued CPUs, so while it's a no-brainer to drop HP-UX support, it's a trickier question for AIX. I guess the way open source is supposed to work is that someone with a real interest in PostgreSQL on AIX helps maintain it, not only keeping it building and passing tests, but making it work really well (cf huge pages, scalable event handling, probably more things that would be obvious to an AIX expert...), and representing ongoing demand and interests from the AIX user community...
Thomas Munro <thomas.munro@gmail.com> writes:
> On Sun, Jul 3, 2022 at 8:34 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> I am a little concerned though that we don't have access to the latest
>> version of AIX --- that seems like a non-maintainable situation.
> The release history doesn't look toooo bad on that front: the live
> versions are 7.1 (2010-2023), 7.2 (2015-TBA) and 7.3 (2021-TBA). 7.3
> only came out half a year ago, slightly after Windows 11, which we
> aren't testing yet either. Those GCC AIX systems seem to be provided
> by IBM and the Open Source Lab at Oregon State University which has a
> POWER lab providing ongoing CI services etc to various OSS projects,
> so I would assume that upgrades (and retirement of the
> about-to-be-desupported 7.1 system) will come along eventually.
OK, we can wait awhile to see what happens on that.
> I don't have a dog in this race, but AIX is clearly not in the same
> category as HP-UX (and maybe Solaris is somewhere in between). AIX
> runs on hardware you can buy today that got a major refresh last year
> (Power 10), while HP-UX runs only on discontinued CPUs, so while it's
> a no-brainer to drop HP-UX support, it's a trickier question for AIX.
Yeah. FTR, I'm out of the HP-UX game: due to a hardware failure,
I can no longer boot that installation. I would have preferred to
keep pademelon, with its pre-C99 compiler, going until v11 is EOL,
but that ain't happening. I see that EDB are still running a couple
of HP-UX/IA64 animals, but I wonder if they're prepared to do anything
to support those animals --- like, say, fix platform-specific bugs.
Robert has definitely indicated displeasure with doing so, but
I don't know if he makes the decisions on that.
I would not stand in the way of dropping HP-UX and IA64 support as of
v16. (I do still feel that HPPA is of interest, to keep us honest
about spinlock support --- but that dual-stack arrangement that IA64
uses is surely not part of anyone's future.)
I have no opinion either way about Solaris.
regards, tom lane
Hi, On 2022-07-04 10:33:37 +1200, Thomas Munro wrote: > I don't have a dog in this race, but AIX is clearly not in the same > category as HP-UX (and maybe Solaris is somewhere in between). The reason to consider whether it's worth supporting AIX is that it's library model is very different from other unix like platforms (much closer to windows though). We also have dedicated compiler support for it, which I guess could separately be dropped. Greetings, Andres Freund
Hi, On 2022-07-03 20:08:19 -0400, Tom Lane wrote: > I would have preferred to keep pademelon, with its pre-C99 compiler, going > until v11 is EOL, but that ain't happening. I'm not too worried about that - clang with -std=c89 -Wc99-extensions -Werror=c99-extensions as it's running on mylodon for the older branches seems to do a decent job. And is obviously much faster :) > I would not stand in the way of dropping HP-UX and IA64 support as of > v16. Cool. > I do still feel that HPPA is of interest, to keep us honest > about spinlock support I.e. forgetting to initialize them? Or the weird alignment stuff it has? I'd started to work a patch to detect missing initialization for both spinlocks and lwlocks, I think that'd be good to have for more common cases. Greetings, Andres Freund
Andres Freund <andres@anarazel.de> writes:
> On 2022-07-03 20:08:19 -0400, Tom Lane wrote:
>> I do still feel that HPPA is of interest, to keep us honest
>> about spinlock support
> I.e. forgetting to initialize them? Or the weird alignment stuff it has?
The nonzero initialization mainly, and to a lesser extent the weird
size of a lock. I think the fact that the active word is only part
of the lock struct is pretty well encapsulated.
> I'd started to work a patch to detect missing initialization for both
> spinlocks and lwlocks, I think that'd be good to have for more common cases.
No objection to having more than one check for this ;-)
regards, tom lane
On Mon, Jul 4, 2022 at 12:08 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > I would not stand in the way of dropping HP-UX and IA64 support as of > v16. (I do still feel that HPPA is of interest, to keep us honest > about spinlock support --- but that dual-stack arrangement that IA64 > uses is surely not part of anyone's future.) I tried to find everything relating to HP-UX, aCC, ia64 and hppa. Or do you still want to keep the hppa bits for NetBSD (I wasn't sure if your threat to set up a NetBSD/hppa system was affected by the hardware failure you mentioned)? Or just leave it in there in orphaned hall-of-fame state, like m68k, m88k, Vax?
Вложения
Thomas Munro <thomas.munro@gmail.com> writes:
> On Mon, Jul 4, 2022 at 12:08 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> I would not stand in the way of dropping HP-UX and IA64 support as of
>> v16. (I do still feel that HPPA is of interest, to keep us honest
>> about spinlock support --- but that dual-stack arrangement that IA64
>> uses is surely not part of anyone's future.)
> I tried to find everything relating to HP-UX, aCC, ia64 and hppa. Or
> do you still want to keep the hppa bits for NetBSD (I wasn't sure if
> your threat to set up a NetBSD/hppa system was affected by the
> hardware failure you mentioned)?
No, the hardware failure is that the machine's SCSI controller seems
to be fried, thus internal drives no longer accessible. I have a
working NetBSD-current installation on an external USB drive, and plan
to commission it as a buildfarm animal once NetBSD 10 is officially
branched. It'll be a frankencritter of the first order, because
USB didn't exist when the machine was built, but hey...
regards, tom lane
Hi, On 2022-07-02 11:33:54 -0700, Andres Freund wrote: > If we decide we want to continue supporting AIX we should bite the bullet and > add a 64bit-int TYPALIGN_*. It might be worth to translate that to bytes when > building tupledescs, so we don't need more branches (reducing them compared to > today). I just thought an easier way - why don't we introduce a 'catalog_double' that's defined to be pg_attribute_aligned(whatever-we-need) on AIX? Then we can get rid of the manually enforced alignedness and we don't need to contort catalog order. Greetings, Andres Freund
Andres Freund <andres@anarazel.de> writes:
> I just thought an easier way - why don't we introduce a 'catalog_double'
> that's defined to be pg_attribute_aligned(whatever-we-need) on AIX? Then we
> can get rid of the manually enforced alignedness and we don't need to contort
> catalog order.
Hm, do all the AIX compilers we care about have support for that?
If so, it seems like a great idea.
regards, tom lane
On 05.07.22 07:31, Andres Freund wrote: > On 2022-07-02 11:33:54 -0700, Andres Freund wrote: >> If we decide we want to continue supporting AIX we should bite the bullet and >> add a 64bit-int TYPALIGN_*. It might be worth to translate that to bytes when >> building tupledescs, so we don't need more branches (reducing them compared to >> today). > > I just thought an easier way - why don't we introduce a 'catalog_double' > that's defined to be pg_attribute_aligned(whatever-we-need) on AIX? Then we > can get rid of the manually enforced alignedness and we don't need to contort > catalog order. Isn't the problem that on AIX, double and int64 have different alignment requirements, and we just check the one for double and apply it to int64? That ought to be fixable by two separate alignment checks in configure and a new alignment letter for pg_type.
Hi, On 2022-07-05 01:36:24 -0400, Tom Lane wrote: > Andres Freund <andres@anarazel.de> writes: > > I just thought an easier way - why don't we introduce a 'catalog_double' > > that's defined to be pg_attribute_aligned(whatever-we-need) on AIX? Then we > > can get rid of the manually enforced alignedness and we don't need to contort > > catalog order. > > Hm, do all the AIX compilers we care about have support for that? > If so, it seems like a great idea. Afaics we support xlc and gcc on AIX, and we enable the attribute for both already. So, I think they do. Greetings, Andres Freund
Hi, On 2022-07-05 08:13:21 +0200, Peter Eisentraut wrote: > On 05.07.22 07:31, Andres Freund wrote: > > On 2022-07-02 11:33:54 -0700, Andres Freund wrote: > > > If we decide we want to continue supporting AIX we should bite the bullet and > > > add a 64bit-int TYPALIGN_*. It might be worth to translate that to bytes when > > > building tupledescs, so we don't need more branches (reducing them compared to > > > today). > > > > I just thought an easier way - why don't we introduce a 'catalog_double' > > that's defined to be pg_attribute_aligned(whatever-we-need) on AIX? Then we > > can get rid of the manually enforced alignedness and we don't need to contort > > catalog order. > > Isn't the problem that on AIX, double and int64 have different alignment > requirements, and we just check the one for double and apply it to int64? > That ought to be fixable by two separate alignment checks in configure and a > new alignment letter for pg_type. Except that that's quite a bit of work to get right, particularly without regressing the performance on all platforms. The attalign switches during tuple deforming are already quite hot. Greetings, Andres Freund
On Tue, Jul 5, 2022 at 4:53 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > Thomas Munro <thomas.munro@gmail.com> writes: > > On Mon, Jul 4, 2022 at 12:08 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > >> I would not stand in the way of dropping HP-UX and IA64 support as of > >> v16. (I do still feel that HPPA is of interest, to keep us honest > >> about spinlock support --- but that dual-stack arrangement that IA64 > >> uses is surely not part of anyone's future.) > > > I tried to find everything relating to HP-UX, aCC, ia64 and hppa. Or > > do you still want to keep the hppa bits for NetBSD (I wasn't sure if > > your threat to set up a NetBSD/hppa system was affected by the > > hardware failure you mentioned)? > > No, the hardware failure is that the machine's SCSI controller seems > to be fried, thus internal drives no longer accessible. I have a > working NetBSD-current installation on an external USB drive, and plan > to commission it as a buildfarm animal once NetBSD 10 is officially > branched. It'll be a frankencritter of the first order, because > USB didn't exist when the machine was built, but hey... OK, here's a new attempt, this time leaving the hppa bits in. The main tricksy bit is where s_lock.h is simplified a bit by moving the fully inline GCC-only hppa support up a bit (it was handled a bit weirdly with some #undef jiggery-pokery before to share stuff between aCC and GCC), making the diff a little hard to follow. Does this make sense? It might also be possible to drop one of __hppa and __hppa__ where they are both tested (not clear to me if that is an aCC/GCC thing). I have no idea if this'll actually work (or ever worked) on NetBSD/hppa... if it comes to it I could try to boot it under qemu-system-hppa if that's what it takes, but it may be easy for you to test...
Вложения
Hi,
On 2022-07-06 14:21:50 +1200, Thomas Munro wrote:
> --- a/src/backend/port/hpux/tas.c.template
> +++ /dev/null
> @@ -1,40 +0,0 @@
> -/*
> - * tas() for HPPA.
> - *
> - * To generate tas.s using this template:
> - * 1. cc +O2 -S -c tas.c
> - * 2. edit tas.s:
> - * - replace the LDW with LDCWX
> - * 3. install as src/backend/port/tas/hpux_hppa.s.
> - *
> - * For details about the LDCWX instruction, see the "Precision
> - * Architecture and Instruction Reference Manual" (09740-90014 of June
> - * 1987), p. 5-38.
> - */
> -
> -int
> -tas(lock)
> - int *lock; /* LDCWX is a word instruction */
> -{
> - /*
> - * LDCWX requires that we align the "semaphore" to a 16-byte
> - * boundary. The actual datum is a single word (4 bytes).
> - */
> - lock = ((uintptr_t) lock + 15) & ~15;
> -
> - /*
> - * The LDCWX instruction atomically clears the target word and
> - * returns the previous value. Hence, if the instruction returns
> - * 0, someone else has already acquired the lock before we tested
> - * it (i.e., we have failed).
> - *
> - * Notice that this means that we actually clear the word to set
> - * the lock and set the word to clear the lock. This is the
> - * opposite behavior from the SPARC LDSTUB instruction. For some
> - * reason everything that H-P does is rather baroque...
> - */
> - if (*lock) { /* this generates the LDW */
> - return(0); /* success */
> - }
> - return(1); /* failure */
> -}
Are these comments retained elsewhere? It's confusing enough that I think we
should make sure they're somewhere until we remove hppa support...
> -#if defined(__ia64__) || defined(__ia64)
> -/*
> - * Intel Itanium, gcc or Intel's compiler.
Hm. Personally I'd do HPUX removal separately from IA64 removal.
Greetings,
Andres Freund
Thomas Munro <thomas.munro@gmail.com> writes:
> OK, here's a new attempt, this time leaving the hppa bits in. The
> main tricksy bit is where s_lock.h is simplified a bit by moving the
> fully inline GCC-only hppa support up a bit (it was handled a bit
> weirdly with some #undef jiggery-pokery before to share stuff between
> aCC and GCC), making the diff a little hard to follow. Does this make
> sense? It might also be possible to drop one of __hppa and __hppa__
> where they are both tested (not clear to me if that is an aCC/GCC
> thing). I have no idea if this'll actually work (or ever worked) on
> NetBSD/hppa... if it comes to it I could try to boot it under
> qemu-system-hppa if that's what it takes, but it may be easy for you
> to test...
Our HEAD does work on that NetBSD installation. I can try this
patch, but it'll take an hour or two to get results ... stay tuned.
I'm not sure about the __hppa vs __hppa__ thing. If we're assuming
that NetBSD is the only remaining hppa platform of interest, then
clearly only one of those is needed, but I don't know which one
should be preferred. It appears that both are defined on NetBSD.
(FWIW, I know that OpenBSD works on this machine too, or did the
last time I tried it. But it probably has the same opinions
as NetBSD about predefined macros.)
regards, tom lane
On Wed, Jul 6, 2022 at 3:26 PM Andres Freund <andres@anarazel.de> wrote: > On 2022-07-06 14:21:50 +1200, Thomas Munro wrote: > > - * Notice that this means that we actually clear the word to set > > - * the lock and set the word to clear the lock. This is the > > - * opposite behavior from the SPARC LDSTUB instruction. For some > > - * reason everything that H-P does is rather baroque... > Are these comments retained elsewhere? It's confusing enough that I think we > should make sure they're somewhere until we remove hppa support... OK, I moved them into s_lock.h where the remaining asm lives. > > -#if defined(__ia64__) || defined(__ia64) > > -/* > > - * Intel Itanium, gcc or Intel's compiler. > > Hm. Personally I'd do HPUX removal separately from IA64 removal. OK, split.
Вложения
Hi, 0001 looks good to me. There's a leftover itanium reference in a comment in src/include/port/atomics/generic-msvc.h There's also a bunch of #ifdef __ia64__ in src/backend/utils/misc/guc-file.c, contrib/seg/segscan.c and contrib/cube/cubescan.c Otherwise lgtm as well. Greetings, Andres Freund
Andres Freund <andres@anarazel.de> writes:
> There's also a bunch of #ifdef __ia64__ in src/backend/utils/misc/guc-file.c,
> contrib/seg/segscan.c and contrib/cube/cubescan.c
And all our other flex output files --- AFAICS that's part of flex's
recipe and not under our control.
regards, tom lane
On 2022-07-06 01:33:58 -0400, Tom Lane wrote: > Andres Freund <andres@anarazel.de> writes: > > There's also a bunch of #ifdef __ia64__ in src/backend/utils/misc/guc-file.c, > > contrib/seg/segscan.c and contrib/cube/cubescan.c > > And all our other flex output files --- AFAICS that's part of flex's > recipe and not under our control. Clearly I need to stop reviewing things for the rest of the day :)
On 06.07.22 04:21, Thomas Munro wrote:
> /*
> * Do not try to collapse these into one "w+" mode file. Doesn't work on
> - * some platforms (eg, HPUX 10.20).
> + * some platforms.
> */
> termin = fopen("/dev/tty", "r");
> termout = fopen("/dev/tty", "w");
I don't know how /dev/tty behaves in detail under stdio. I think
removing this part of the comment might leave the impression that
attempting to use "w+" will never work, whereas the existing comment
appears to indicate that it was only very old platforms that had the
issue. If we don't have an immediate answer to that, I'd leave the
comment as is.
Peter Eisentraut <peter.eisentraut@enterprisedb.com> writes:
> On 06.07.22 04:21, Thomas Munro wrote:
>> /*
>> * Do not try to collapse these into one "w+" mode file. Doesn't work on
>> - * some platforms (eg, HPUX 10.20).
>> + * some platforms.
>> */
>> termin = fopen("/dev/tty", "r");
>> termout = fopen("/dev/tty", "w");
> I don't know how /dev/tty behaves in detail under stdio. I think
> removing this part of the comment might leave the impression that
> attempting to use "w+" will never work, whereas the existing comment
> appears to indicate that it was only very old platforms that had the
> issue. If we don't have an immediate answer to that, I'd leave the
> comment as is.
Yeah, I was kind of wondering whether we should give w+ a try now.
IIRC, the code was like that at one point, but we had to change it
(ie the comment comes from bitter experience). On the other hand,
it's probably not worth the trouble and risk to change it again.
regards, tom lane
I wrote:
> Our HEAD does work on that NetBSD installation. I can try this
> patch, but it'll take an hour or two to get results ... stay tuned.
Indeed, I still get a clean build and "make check" passes with
this patch.
regards, tom lane
On Sat, Jul 2, 2022 at 2:34 PM Andres Freund <andres@anarazel.de> wrote: > I strikes me as a remarkably bad idea to manually try to maintain the correct > alignment. Even with the tests added it's still quite manual and requires > contorted struct layouts (see e.g. [1]). > > I think we should either teach our system the correct alignment rules or we > should drop AIX support. I raised this same issue at http://postgr.es/m/CA+TgmoaK377MXCWJqEXM3VvKDDC-frNUMKb=7u07TJa59wTAeQ@mail.gmail.com and discussion ensued from there. I agree that manually maintaining alignment, even with a regression test to help, is a really bad plan. The rule about columns of type "name" can be relaxed easily enough, just by insisting that NAMEDATALEN must be a multiple of 8. As Tom also said on this thread, adding such a constraint seems to have no real downside. But the problem has a second aspect not related to NameData, which is that int64 and double have different alignment requirements on that platform. To get out from under that part of it, it seems we either need to de-support AIX and any other platforms that have such a discrepancy, or else have separate typalign values for int64-align vs. double-align. From a theoretical point of view, I think what we're doing now is pretty unprincipled. I've always found it a bit surprising that we get away with just assuming that a bunch of various different primitive data types are all going to have the same alignment requirement. The purist in me feels that it would be better to have separate typalign values for things that aren't guaranteed to behave the same. However, there's a practical difficulty with that approach: if the only operating system where this issue occurs in practice is AIX, I feel it's going to be pretty hard for us to keep the code that caters to this unusual situation working properly. And I'd rather have no code for it at all than have code which doesn't really work. -- Robert Haas EDB: http://www.enterprisedb.com
Hi, On 2022-07-06 11:55:57 -0400, Robert Haas wrote: > On Sat, Jul 2, 2022 at 2:34 PM Andres Freund <andres@anarazel.de> wrote: > > I strikes me as a remarkably bad idea to manually try to maintain the correct > > alignment. Even with the tests added it's still quite manual and requires > > contorted struct layouts (see e.g. [1]). > > > > I think we should either teach our system the correct alignment rules or we > > should drop AIX support. > > I raised this same issue at > http://postgr.es/m/CA+TgmoaK377MXCWJqEXM3VvKDDC-frNUMKb=7u07TJa59wTAeQ@mail.gmail.com > and discussion ensued from there. I agree that manually maintaining > alignment, even with a regression test to help, is a really bad plan. > > The rule about columns of type "name" can be relaxed easily enough, > just by insisting that NAMEDATALEN must be a multiple of 8. As Tom > also said on this thread, adding such a constraint seems to have no > real downside. But the problem has a second aspect not related to > NameData, which is that int64 and double have different alignment > requirements on that platform. To get out from under that part of it, > it seems we either need to de-support AIX and any other platforms that > have such a discrepancy, or else have separate typalign values for > int64-align vs. double-align. I think my proposal of introducing a version of double that is marked to be 8 byte aligned should do the trick as well, and doesn't have the problem of changing the meaning of 'double' references in external headers. In fact, we already have float8 as a type, so we could just add it there. We don't currently have a float8 in the catalogs afaics, but I think it'd be better to not rely on that. It's not pretty, but still seems a lot better than doing this stuff manually. > From a theoretical point of view, I think what we're doing now is > pretty unprincipled. I've always found it a bit surprising that we get > away with just assuming that a bunch of various different primitive > data types are all going to have the same alignment requirement. The > purist in me feels that it would be better to have separate typalign > values for things that aren't guaranteed to behave the same. However, > there's a practical difficulty with that approach: if the only > operating system where this issue occurs in practice is AIX, I feel > it's going to be pretty hard for us to keep the code that caters to > this unusual situation working properly. And I'd rather have no code > for it at all than have code which doesn't really work. The problem with having a lot more alignment values is that it adds a bunch of overhead to very performance critical paths. We don't want to add more branches to att_align_nominal() if we can avoid it. I guess we can try to introduce TYPALIGN_INT64 and then hide the relevant branch with an ifdef for the common case of TYPALIGN_INT64 == TYPALIGN_DOUBLE. I'm fairly certain that we're going to add a lot more 64bit ints to catalogs in the next few years, so this will become a bigger issue over time... Outside of the catalogs I still think that we should work towards not aligning byval values (and instead memcpy-ing the values to deal with alignment sensitive platforms), so we don't waste so much space. And for catalogs we've been talking about giving up the struct mapping as well, in the thread about variable length names. In which case we could the cost of handling more alignment values wouldn't be incurred as frequently. Greetings, Andres Freund
On Wed, Jul 6, 2022 at 12:27 PM Andres Freund <andres@anarazel.de> wrote: > I think my proposal of introducing a version of double that is marked to be 8 > byte aligned should do the trick as well, and doesn't have the problem of > changing the meaning of 'double' references in external headers. In fact, we > already have float8 as a type, so we could just add it there. Yeah, but how easily will it be to know whether we've used that in every relevant place? Could we insist on 8-byte alignment even on 32-bit platforms? I think we have a few of those in the buildfarm, so maybe that would help us spot problems. Although I'm not sure how, exactly. > The problem with having a lot more alignment values is that it adds a bunch of > overhead to very performance critical paths. We don't want to add more > branches to att_align_nominal() if we can avoid it. Fair. > I'm fairly certain that we're going to add a lot more 64bit ints to catalogs > in the next few years, so this will become a bigger issue over time... Absolutely. > Outside of the catalogs I still think that we should work towards not aligning > byval values (and instead memcpy-ing the values to deal with alignment > sensitive platforms), so we don't waste so much space. And for catalogs we've > been talking about giving up the struct mapping as well, in the thread about > variable length names. In which case we could the cost of handling more > alignment values wouldn't be incurred as frequently. +1. Aligning stuff on disk appears to have few redeeming properties for the amount of pain it causes. -- Robert Haas EDB: http://www.enterprisedb.com
On Thu, Jul 7, 2022 at 1:02 AM Peter Eisentraut
<peter.eisentraut@enterprisedb.com> wrote:
> On 06.07.22 04:21, Thomas Munro wrote:
> > /*
> > * Do not try to collapse these into one "w+" mode file. Doesn't work on
> > - * some platforms (eg, HPUX 10.20).
> > + * some platforms.
> > */
> > termin = fopen("/dev/tty", "r");
> > termout = fopen("/dev/tty", "w");
>
> I don't know how /dev/tty behaves in detail under stdio. I think
> removing this part of the comment might leave the impression that
> attempting to use "w+" will never work, whereas the existing comment
> appears to indicate that it was only very old platforms that had the
> issue. If we don't have an immediate answer to that, I'd leave the
> comment as is.
Thanks. I put that bit back, removed the stray mention of "itanium"
in Windows-specific stuff that Andres mentioned, and pushed these
patches.
While adjusting the docs, I noticed a few little inconsistencies here
and there for other ISAs.
* The documented list of ISAs should by now mention RISC-V. I'm sure
it needs some fine tuning but it's working fine and tested by the
build farm.
* The documented list mentions some in different endiannesses and word
sizes explicitly but not others; I think it'd be tidier to list the
main architecture names and then tack on a "big and little endian, 32
and 64 bit" sentence.
* Under "code exists, not tested" we mentioned M68K, M32R, VAX, but
M88K and SuperH are also in that category and have been added/tweaked
in the past decade with reports that imply that they were working on
retro-gear. AFAIK only SuperH-family stuff is still produced. I
don't know much about that and I'm not planning to change anything,
except one special mention...
* Since Greg Stark's magnificent Vax talk[1], we became even more
dependent on IEEE 754 via the Ryu algorithm. AFAICT, unless someone
produces a software IEEE math implementation for GCC/VAX... if I had
a pick one to bump off that list, that's the easiest to argue because
it definitely doesn't work.
* When we removed Alpha we left a couple of traces.
What do you think about the attached?
[1] https://archive.fosdem.org/2016/schedule/event/postgresql_on_vax/
Вложения
Thomas Munro <thomas.munro@gmail.com> writes:
> * The documented list mentions some in different endiannesses and word
> sizes explicitly but not others; I think it'd be tidier to list the
> main architecture names and then tack on a "big and little endian, 32
> and 64 bit" sentence.
As phrased, this seems to be saying that we can do both
endiannesses on any of the supported arches, which is a little
weird considering that most of them are single-endianness. It's
not a big deal, but maybe a tad more word-smithing there would
help?
> * Since Greg Stark's magnificent Vax talk[1], we became even more
> dependent on IEEE 754 via the Ryu algorithm. AFAICT, unless someone
> produces a software IEEE math implementation for GCC/VAX... if I had
> a pick one to bump off that list, that's the easiest to argue because
> it definitely doesn't work.
Agreed. In principle I'd wish that we were not tied to one
floating-point format, but the benefits of Ryu are too hard to
pass up; and reality on the ground is that IEEE 754 achieved
total victory a couple decades ago. We should stop claiming
that VAX is a realistic target platform.
> What do you think about the attached?
WFM. Also, that crypt-blowfish.c hunk offers an answer to
your question about whether to worry about "__hppa".
regards, tom lane
On Thu, 7 Jul 2022 at 22:36, Thomas Munro <thomas.munro@gmail.com> wrote: > > * Since Greg Stark's magnificent Vax talk[1], we became even more > dependent on IEEE 754 via the Ryu algorithm. AFAICT, unless someone > produces a software IEEE math implementation for GCC/VAX... if I had > a pick one to bump off that list, that's the easiest to argue because > it definitely doesn't work. Yeah that's definitely true. I think you could possibly build with a software fp implementation but then you would have to recompile libc and any other libraries as well. If it was worth spending a lot of effort we could perhaps separate the Float4/Float8 data type from the core C code floating point and compile with just the former using soft floats but use native floats for core code. That's probably way more effort than it's worth for VAX but it would conceivably be worthwhile if it helped for running on some embedded platform but I don't think so since they would presumably be using soft floats everywhere anyways. -- greg
On Tue, Jul 5, 2022 at 1:32 AM Andres Freund <andres@anarazel.de> wrote:
> I just thought an easier way - why don't we introduce a 'catalog_double'
> that's defined to be pg_attribute_aligned(whatever-we-need) on AIX? Then we
> can get rid of the manually enforced alignedness and we don't need to contort
> catalog order.
I investigated this a little bit today. It seems that
att_align_nominal() thinks that typalign=='d' means ALIGNOF_DOUBLE,
which on AIX is 4. So I think what we would need to do first is
redefine typalign=='d' to mean alignment to MAXIMUM_ALIGNOF. If we
don't do that, then there's no automatic way to get uint64 fields to
be placed on 8-byte boundaries, which it requires. Such a change would
have no effect on many systems, but if as on AIX double requires less
alignment than either "long" or "long long int", it will break on-disk
compatibility and in particular pg_upgrade compatibility.
If we did that, then we could pursue your proposal above. Rather than
creating an altogether new typedef, we could just apply
pg_attribute_aligned(MAXIMUM_ALIGNOF) to the existing typedef for
float8, which is documented as being the name that should be used in
the catalogs, and is. Since pg_attribute_aligned() is not supported on
all platforms, we elsewhere apply it conditionally, so we would
presumably do the same thing here. That would mean that it might fail
to apply on some platform somewhere, but we could compensate for that
by adding a static assertion checking that if we do struct
float8_alignmment_test { char pad; float8 x; } then
alignof(float8_alignment_test, x) == MAXIMUM_ALIGNOF. That way, if
pg_attribute_aligned() isn't supported but the platform doesn't have
this issue in the first place, all is well. If pg_attribute_aligned()
isn't supported and the platform does have this issue, compilation
will fail.
In theory, we could have the same issue with int64 on some other
platform. On this hypothetical system, ALIGNOF_LONG_LONG_INT <
ALIGNOF_DOUBLE. The compile would then align int64 catalog columns on,
say, 4-byte boundaries, but our tuple deforming code would think that
they were aligned to 8 byte boundaries. We could fix that by forcing
the int64 type to have maximum alignment as well or introducing a new
typedef that does. However, such a fix could probably be postponed
until such time as a system of this kind turns up. It might never
happen.
--
Robert Haas
EDB: http://www.enterprisedb.com
On Fri, Jul 8, 2022 at 4:24 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > Thomas Munro <thomas.munro@gmail.com> writes: > > * The documented list mentions some in different endiannesses and word > > sizes explicitly but not others; I think it'd be tidier to list the > > main architecture names and then tack on a "big and little endian, 32 > > and 64 bit" sentence. > > As phrased, this seems to be saying that we can do both > endiannesses on any of the supported arches, which is a little > weird considering that most of them are single-endianness. It's > not a big deal, but maybe a tad more word-smithing there would > help? OK, I word-smothe thusly: + and PA-RISC, including + big-endian, little-endian, 32-bit, and 64-bit variants where applicable. I also realised that we should list a couple more OSes (we know they work, they are automatically tested). Then I wondered why we bother to state a Windows version here. For consistency, we could list the minimum Linux kernel, and so on for every other OS, but that's silly for such brief and general documentation. So I propose that we just say "current versions of ..." and remove the bit about Windows 10.
Вложения
Thomas Munro <thomas.munro@gmail.com> writes:
> OK, I word-smothe thusly:
> + and PA-RISC, including
> + big-endian, little-endian, 32-bit, and 64-bit variants where applicable.
WFM. I also wonder if in
+ <productname>PostgreSQL</productname> can be expected to work on current
+ versions of these operating systems: Linux (all recent distributions), Windows,
+ FreeBSD, OpenBSD, NetBSD, DragonFlyBSD, macOS, AIX, Solaris, and illumos.
we could drop "(all recent distributions)", figuring that "current
versions" covers that already. Other than that niggle, this
looks good to me.
regards, tom lane
On Mon, Jul 11, 2022 at 11:38 AM Tom Lane <tgl@sss.pgh.pa.us> wrote: > WFM. I also wonder if in > > + <productname>PostgreSQL</productname> can be expected to work on current > + versions of these operating systems: Linux (all recent distributions), Windows, > + FreeBSD, OpenBSD, NetBSD, DragonFlyBSD, macOS, AIX, Solaris, and illumos. > > we could drop "(all recent distributions)", figuring that "current > versions" covers that already. Other than that niggle, this > looks good to me. Yeah. I wasn't too sure if that was mostly about "recent" or mostly about "all distributions" but it wasn't doing much. Thanks, pushed.
Thomas Munro <thomas.munro@gmail.com> writes:
> Yeah. I wasn't too sure if that was mostly about "recent" or mostly
> about "all distributions" but it wasn't doing much. Thanks, pushed.
While we're here ...
+ Code support exists for M68K, M88K, M32R, and SuperH, but these
architectures are not known to have been tested recently.
I confess great fondness for M68K, having spent a goodly chunk of
the eighties hacking M68K assembly code. However, of these four
architectures, I fear only SuperH has anything resembling a
detectable pulse. According to Wikipedia:
* Motorola ended development of M68K in 1994. The last processors
had clock rates around 75MHz (and this was a CISC architecture,
so instruction rates were a good bit less). Considering how
depressingly slow my late-90s 360MHz HPPA box is, it's impossible
to believe that anyone wants to run PG on M68K today.
* M88K was introduced in 1988 and discontinued in 1991. Max clock
rate was apparently somewhere under 100MHz, and in any case it's
hard to believe that any remain alive in the wild.
* M32R ... hard to tell for sure, because Wikipedia's only concrete
info is a link to a 404 page at renasas.com. But they do say that
the Linux kernel dropped support for it some years ago.
SuperH might be twitching a bit less feebly than these three,
but it seems to be a legacy architecture as well. Not much
has happened there since the early 2000's AFAICS.
I think it'd be pretty reasonable to disclaim support for
any architecture that doesn't have a representative in our
buildfarm, which would lead to dropping all four of these.
If you don't like it, step up and run a buildfarm animal.
(The same policy could be applied to operating systems,
but it looks like we're good on that side.)
regards, tom lane
On Mon, Jul 11, 2022 at 6:49 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > SuperH might be twitching a bit less feebly than these three, > but it seems to be a legacy architecture as well. Not much > has happened there since the early 2000's AFAICS. It looks like there's an sh3el package for PostgreSQL on NetBSD here, so whoever maintains that might be in touch: https://ftp.netbsd.org/pub/pkgsrc/current/pkgsrc/databases/postgresql14-server/index.html > I think it'd be pretty reasonable to disclaim support for > any architecture that doesn't have a representative in our > buildfarm, which would lead to dropping all four of these. > If you don't like it, step up and run a buildfarm animal. +1 It's funny to think that you probably could run modern PostgreSQL on the Sun 3 boxes the project started on in 1986 (based on clues from the papers in our history section) if you put NetBSD on them, but you'd probably need to cross compile due to lack of RAM. The grammar in particular.
On Mon, Jul 11, 2022 at 2:49 AM Tom Lane <tgl@sss.pgh.pa.us> wrote: > While we're here ... > > + Code support exists for M68K, M88K, M32R, and SuperH, but these > architectures are not known to have been tested recently. > > I think it'd be pretty reasonable to disclaim support for > any architecture that doesn't have a representative in our > buildfarm, which would lead to dropping all four of these. > If you don't like it, step up and run a buildfarm animal. +1. Keeping stuff like this in the documentation doesn't make those platforms supported. What it does do is make it look like we're bad at updating our documentation. I strongly suspect that anyone who tried to use a modern PostgreSQL on any of these platforms would find it quite an adventure, which is fine, because if you're trying to use any of those platforms in 2022, you are probably the sort of person who enjoys an adventure. But it can't really be useful to list them in the documentation, and it's unlikely that any of them "just work". -- Robert Haas EDB: http://www.enterprisedb.com
Robert Haas <robertmhaas@gmail.com> writes:
> On Mon, Jul 11, 2022 at 2:49 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> I think it'd be pretty reasonable to disclaim support for
>> any architecture that doesn't have a representative in our
>> buildfarm, which would lead to dropping all four of these.
>> If you don't like it, step up and run a buildfarm animal.
> I strongly suspect that anyone who tried to use a modern PostgreSQL on
> any of these platforms would find it quite an adventure, which is
> fine, because if you're trying to use any of those platforms in 2022,
> you are probably the sort of person who enjoys an adventure. But it
> can't really be useful to list them in the documentation, and it's
> unlikely that any of them "just work".
It's possible that they "just work", but we have no way of knowing that,
or knowing if we break them in future. Thus the importance of having
a buildfarm animal to tell us that.
More generally, I think the value of carrying support for niche
architectures is that it helps keep us from falling into the
software-monoculture trap, from which we'd be unable to escape when
the hardware landscape inevitably changes. However, it only helps
if somebody is testing such arches on a regular basis. The fact that
there's some #ifdef'd code somewhere for M88K proves diddly-squat
about whether we could actually run on M88K today. The situation
for niche operating systems is precisely analogous.
regards, tom lane
Thomas Munro <thomas.munro@gmail.com> writes: > On Mon, Jul 11, 2022 at 6:49 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: >> SuperH might be twitching a bit less feebly than these three, >> but it seems to be a legacy architecture as well. Not much >> has happened there since the early 2000's AFAICS. > It looks like there's an sh3el package for PostgreSQL on NetBSD here, > so whoever maintains that might be in touch: > https://ftp.netbsd.org/pub/pkgsrc/current/pkgsrc/databases/postgresql14-server/index.html Hm. For a moment there I was feeling bad about recommending cutting off a platform somebody still pays attention to ... but looking at the relevant NetBSD mailing list archives makes it look like that port is pretty darn moribund. > It's funny to think that you probably could run modern PostgreSQL on > the Sun 3 boxes the project started on in 1986 (based on clues from > the papers in our history section) if you put NetBSD on them, but > you'd probably need to cross compile due to lack of RAM. Yeah. I'm wondering if that sh3el package was cross-compiled, and if so whether it was just part of a mass package build rather than something somebody was specifically interested in. You'd have to be a glutton for pain to want to do actual work with PG on the kind of SH3 hardware that seems to be available. regards, tom lane
On Tue, Jul 12, 2022 at 7:24 AM Tom Lane <tgl@sss.pgh.pa.us> wrote: > Thomas Munro <thomas.munro@gmail.com> writes: > > It's funny to think that you probably could run modern PostgreSQL on > > the Sun 3 boxes the project started on in 1986 (based on clues from > > the papers in our history section) if you put NetBSD on them, but > > you'd probably need to cross compile due to lack of RAM. > > Yeah. I'm wondering if that sh3el package was cross-compiled, > and if so whether it was just part of a mass package build rather > than something somebody was specifically interested in. You'd > have to be a glutton for pain to want to do actual work with PG > on the kind of SH3 hardware that seems to be available. /me pictures Stark wheeling a real Sun 3 into a conference room Yeah, we can always consider putting SuperH back if someone showed up to maintain/test it. That seems unlikely, but apparently there's an open source silicon project based on this ISA, so maybe a fast one isn't impossible... Here's a patch to remove all of these. I didn't originally suggest that because of some kind of (mostly vicarious) nostalgia. I wonder if we should allow ourselves a paragraph where we remember these systems. I personally think it's one of the amazing things about this project. Here's what I came up with, but I'm sure there are more.
Вложения
Thomas Munro <thomas.munro@gmail.com> writes:
> Here's a patch to remove all of these.
Looks sane by eyeball --- I didn't grep for other references, though.
> I didn't originally suggest that because of some kind of (mostly
> vicarious) nostalgia. I wonder if we should allow ourselves a
> paragraph where we remember these systems. I personally think it's
> one of the amazing things about this project. Here's what I came up
> with, but I'm sure there are more.
PlayStation 2 [1]? Although I suppose that falls under MIPS,
which probably means we could still run on it, if you can find one.
regards, tom lane
[1] https://www.postgresql.org/message-id/flat/05e101c1834a%24e398b920%24f90e10ac%40toronto.redhat.com
On Tue, Jul 12, 2022 at 10:30 AM Tom Lane <tgl@sss.pgh.pa.us> wrote: > Thomas Munro <thomas.munro@gmail.com> writes: > > Here's a patch to remove all of these. > > Looks sane by eyeball --- I didn't grep for other references, though. Thanks, pushed. > > I didn't originally suggest that because of some kind of (mostly > > vicarious) nostalgia. I wonder if we should allow ourselves a > > paragraph where we remember these systems. I personally think it's > > one of the amazing things about this project. Here's what I came up > > with, but I'm sure there are more. > > PlayStation 2 [1]? Although I suppose that falls under MIPS, > which probably means we could still run on it, if you can find one. Yeah. PS had MIPS, then PowerPC (Cell), and currently AMD (interestingly they also run a modified FreeBSD kernel, but you can't really get at it...). Sega Dreamcast had SH4. I added one more: Tru64 (but I didn't bother to list Digital UNIX or OSF/1, not sure if software historians consider those different OSes or just rebrands...). Patches to improve this little paragraph welcome. Pushed.