On Tue, Jul 12, 2022 at 10:30 AM Tom Lane wrote:
> Thomas Munro 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)
Thomas Munro 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
On Tue, Jul 12, 2022 at 7:24 AM Tom Lane wrote:
> Thomas Munro 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
Thomas Munro writes:
> On Mon, Jul 11, 2022 at 6:49 PM Tom Lane 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
Robert Haas writes:
> On Mon, Jul 11, 2022 at 2:49 AM Tom Lane 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
On Mon, Jul 11, 2022 at 2:49 AM Tom Lane 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
On Mon, Jul 11, 2022 at 6:49 PM Tom Lane 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,
Thomas Munro 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
On Mon, Jul 11, 2022 at 11:38 AM Tom Lane wrote:
> WFM. I also wonder if in
>
> + PostgreSQL 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
Thomas Munro 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
+ PostgreSQL can be expected to work on current
+ versions of these operating systems: Linux (all recent
On Fri, Jul 8, 2022 at 4:24 PM Tom Lane wrote:
> Thomas Munro 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
> >
On Tue, Jul 5, 2022 at 1:32 AM Andres Freund 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
On Thu, 7 Jul 2022 at 22:36, Thomas Munro 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,
Thomas Munro 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
On Thu, Jul 7, 2022 at 1:02 AM Peter Eisentraut
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.
> >*/
> >
On Wed, Jul 6, 2022 at 12:27 PM Andres Freund 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
Hi,
On 2022-07-06 11:55:57 -0400, Robert Haas wrote:
> On Sat, Jul 2, 2022 at 2:34 PM Andres Freund 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
On Sat, Jul 2, 2022 at 2:34 PM Andres Freund 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
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
Peter Eisentraut 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");
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");
On 2022-07-06 01:33:58 -0400, Tom Lane wrote:
> Andres Freund 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
Andres Freund 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
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
On Wed, Jul 6, 2022 at 3:26 PM Andres Freund 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
Thomas Munro 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
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
On Tue, Jul 5, 2022 at 4:53 PM Tom Lane wrote:
> Thomas Munro writes:
> > On Mon, Jul 4, 2022 at 12:08 PM Tom Lane 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
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
Hi,
On 2022-07-05 01:36:24 -0400, Tom Lane wrote:
> Andres Freund 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
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
Andres Freund 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
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
>
Thomas Munro writes:
> On Mon, Jul 4, 2022 at 12:08 PM Tom Lane 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
On Mon, Jul 4, 2022 at 12:08 PM Tom Lane 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
Andres Freund 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
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
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
Thomas Munro writes:
> On Sun, Jul 3, 2022 at 8:34 AM Tom Lane 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 t bad on that front: the live
> versions are
On Sun, Jul 3, 2022 at 8:34 AM Tom Lane 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 t bad on that front: the live
versions are 7.1 (2010-2023), 7.2
Andres Freund 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
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).
Peter Geoghegan 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
On Sat, Jul 2, 2022 at 12:22 PM Tom Lane 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
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
Peter Geoghegan 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
On Sat, Jul 2, 2022 at 11:34 AM Andres Freund 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
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
Date: 2016-12-21 12:00:00 -0500
48 matches
Mail list logo
