Hi Laurenz, we are working on the other file changes, we shall post you the
updates soon.
Warm regards,
Sriram.
On Fri, 2024-06-07 at 16:30 +, Srirama Kucherlapati wrote:
> Hi Team, We are pursuing to trim the changes wrt AIX. As of now we trimmed
> the changes with respect to XLC and currently with trimmed changes the
> buildfarm script passed (build and all the regression tests)
> The XLC changes were
Hi Team, We are pursuing to trim the changes wrt AIX. As of now we trimmed
the changes with respect to XLC and currently with trimmed changes the
buildfarm script passed (build and all the regression tests)
The XLC changes were trimmed only in the below file
modified: configure
modified:
On Thu, May 23, 2024 at 07:03:20PM +0300, Heikki Linnakangas wrote:
> > Can you provide some more details on the expectations here?
>
> Smallest possible patch that makes Postgres work on AIX again.
>
> Perhaps start with the patch you posted yesterday, but remove hunks from it
> one by one, to
waiting for
all the hacks to be fixed.
I'm not eager to put back those hacks just to have them be removed
again. So I'd like to see a minimal patch, with the *minimal* changes
required for AIX support. And perhaps split that into two patches: First
add back AIX support with GCC, and second patch
Hi Peter, thanks for your feedback.
We are eager to extend our support in resolving the issues specific to AIX or
corresponding
compilers (XLC and cLang).
But as there are no issues with the patch after reverting the changes(with the
latest compilers
gcc12 and xlc-16.0.1.18), we were wondering
On 22.05.24 18:15, Sriram RK wrote:
Please find the attached patch.
Apart from the AIX specific changes, there is a minor change in this
file wrt to XLC, below is the error for which we removed inline.
Later, the build and tests passed for both XLC(16.1.0.18) and gcc(12) as
well.
I think
".
gmake[4]: *** [: bufmgr.o] Error 1
Please let us know your feedback.
Thanks,
Sriram.
0001-AIX-support-revert-the-changes-from-0b16bb8776bb8.patch
Description: 0001-AIX-support-revert-the-changes-from-0b16bb8776bb8.patch
On 2024-May-16, Sriram RK wrote:
> Hi Team,
>
> We have an update wrt to the PG17 AIX port.
>
> We have reverted the changes specific to AIX (that were removed in
> 0b16bb8776bb8) to the latest PG17 (head).
>
> The Buildfarm succeeded for these changes. All the tests passed.
Excellent.
>
Hi Team,
We have an update wrt to the PG17 AIX port.
We have reverted the changes specific to AIX (that were removed in
0b16bb8776bb8) to the latest PG17 (head).
The Buildfarm succeeded for these changes. All the tests passed.
System config
OS level : AIX-73D
> > Also would like to know some info related to the request raised for
> > buildfarm access, to register the
> > node in OSU lab. Where can I get the status of the request? Whom can I
> > contact to get the request
> > approved? So that we can add the node to the buildfarm.
> I assume you
On Wed, May 15, 2024 at 03:33:25PM +, Sriram RK wrote:
> Hi Team, we have any updated from the XLC team, the issue specific to the
> alignment is fixed
> and XLC had released it as part of 16.1.0.18. The PTF is available at the
> below location,
>
> You can also find a link here:
>
Hi Team, we have any updated from the XLC team, the issue specific to the
alignment is fixed
and XLC had released it as part of 16.1.0.18. The PTF is available at the below
location,
You can also find a link here:
https://www.ibm.com/support/pages/fix-list-xl-cc-aix.
; submit a patch for new, modernized AIX support for PG18.
Yes, I think we were clear that someone needs to review the reverted
patch and figure out which parts are still needed, and why. We have no
"plans" to restore support.
--
Bruce Momjian https://momjian.us
EDB
On 08.05.24 13:39, Sriram RK wrote:
We would like to understand your inputs/plans on reverting the changes
for AIX.
I think the ship has sailed for PG17. The way forward would be that you
submit a patch for new, modernized AIX support for PG18.
Hi Team, We have the AIX node ready in OSU lab, and the branches 15 and 16 got
build on the node. We had raised a request to register this node as buildfarm
member. Yet to receive the approval.
We would like to understand your inputs/plans on reverting the changes for AIX.
Thanks,
Sriram.
Hi Team, on further investigation we were able to resolve the perl issue by
setting the right PERL env location. Earlier it was pointing to the 32bit perl,
as a result the perl lib mismatch seems to be happening.
Now we have successfully built release 15 and 16 stable branches on the OSU lab
Hi Team,
There are couple of updates, firstly we got an AIX node on the OSU lab.
Please feel free to reach me, so that we can provide access to the node.
We have started working on setting up the buildfarm on that node.
Secondly, as part of the buildfarm setup on our local nodes, we are hitting
> > It would definitely make sense for a new port to start by getting
> > things going with gcc only, and then look at resurrecting xlc
> > support.
> Sriram mentioned upthread that he was looking at both of them. I'd be
> ready to assume that most of the interest is in xlc, not gcc. But I
>
On Thu, Apr 25, 2024 at 01:06:24PM +0900, Michael Paquier wrote:
> Anyway, getting an access to such compilers to be able to debug issues
> on hosts that take less than 12h to just compile the code would
> certainly help its adoption. So seeing commitment in the form of
> patches and access to
On Thu, Apr 25, 2024 at 10:16:34AM +0200, Álvaro Herrera wrote:
> On 2024-Apr-24, Bruce Momjian wrote:
>
> > I agree that targeting PG 18 for a new-er AIX port is the reasonable
> > approach. If there is huge demand, someone can create an AIX fork for
> > PG 17 using the reverted patches ---
Hi,
On 2024-04-25 00:20:05 -0400, Tom Lane wrote:
> Something I've been mulling over is whether to suggest that the
> proposed "new port" should only target building with gcc.
Yes. I also wonder if such a port should only support building with sysv
style shared library support, rather than the
Peter Eisentraut writes:
> On 25.04.24 06:20, Tom Lane wrote:
>> Something I've been mulling over is whether to suggest that the
>> proposed "new port" should only target building with gcc.
> My understanding is that the old xlc is dead and has been replaced by
> "xlclang", which is presumably
On 2024-Apr-24, Bruce Momjian wrote:
> I agree that targeting PG 18 for a new-er AIX port is the reasonable
> approach. If there is huge demand, someone can create an AIX fork for
> PG 17 using the reverted patches --- yeah, lots of pain there, but we
> have carried the AIX pain for too long
On 25.04.24 06:20, Tom Lane wrote:
Something I've been mulling over is whether to suggest that the
proposed "new port" should only target building with gcc.
On the one hand, that would (I think) remove a number of annoying
issues, and the average end user is unlikely to care which compiler
On Thu, Apr 25, 2024 at 12:20:05AM -0400, Tom Lane wrote:
> It would definitely make sense for a new port to start by getting
> things going with gcc only, and then look at resurrecting xlc
> support.
Sriram mentioned upthread that he was looking at both of them. I'd be
ready to assume that most
Michael Paquier writes:
> Some of the portability changes removed in 0b16bb877 feel indeed
> obsolete, so it may not hurt to start an analysis from scratch to see
> the minimum amount of work that would be really required with the
> latest versions of xlc, using the newest compilers as a
ant to just revert the AIX-ectomy and continue drifting.
>>
>> On the whole, it wouldn't be the worst thing in the world if PG 17
>> lacks AIX support but that comes back in PG 18. That approach would
>> solve the schedule-crunch aspect and give time for considered review
>> of h
On Sat, Apr 20, 2024 at 12:25:47PM -0400, Tom Lane wrote:
> > I can see several ways going forward:
> > 1. We revert the removal of AIX support and carry on with the status quo
> > ante. (The removal of AIX is a regression; it is timely and in scope
> > now to revert the
On Sat Apr 20, 2024 at 10:42 AM CDT, Peter Eisentraut wrote:
3. We leave it out of PG17 and consider a new AIX port for PG18 on its
own merits.
Note that such a "new" port would probably require quite a bit of
development and research work, to clean up all the cruft that had
accumulated
Hi Team,
> I have some sympathy for this. The discussion about removing AIX
> support had a very short turnaround and happened in an unrelated thread,
> without any sort of public announcement or consultation. So this report
> of "hey, we were still using that" is ti
Peter Eisentraut writes:
> I have some sympathy for this. The discussion about removing AIX
> support had a very short turnaround and happened in an unrelated thread,
> without any sort of public announcement or consultation. So this report
> of "hey, we were still usin
AIX support back into PG17.
I have some sympathy for this. The discussion about removing AIX
support had a very short turnaround and happened in an unrelated thread,
without any sort of public announcement or consultation. So this report
of "hey, we were still using that" is timel
For any complier/hardware related issue we should able to provide support.
We are in the process of identifying the AIX systems that can be added to the
CI/buildfarm environment.
Regards,
Sriram.
h,
long after many threads on this list that between-the-lines threatened
to drop support.
> This is generally one of the big issues with AIX support. There are other
> niche-y OSs that don't have a lot of users, e.g. openbsd, but in contrast to
> AIX I can just start an openbsd VM with
ave to rely on whatever the aix machines there provide. They're not
particularly plentiful resource-wise either.
This is generally one of the big issues with AIX support. There are other
niche-y OSs that don't have a lot of users, e.g. openbsd, but in contrast to
AIX I can just start an openbsd V
> Let's start by setting up a new AIX buildfarm member. Regardless of what we
> do with v17, we continue to support AIX on the stable branches, and we really
> need a buildfarm member to keep the stable branches working anyway.
Thanks Heikki. We had already build the source code(v17+
available. But for time being can we start
>reverting the patch that has removed AIX support.
Let's start by setting up a new AIX buildfarm member. Regardless of what we do
with v17, we continue to support AIX on the stable branches, and we really need
a buildfarm member to keep the
of the support, we will help in fixing all the issues related to
AIX and continue to support AIX for Postgres. If we need another CI environment
we can work to make one available. But for time being can we start reverting
the patch that has removed AIX support.
We want to make a note
On Fri, Apr 05, 2024 at 04:12:06PM +, Sriram RK wrote:
>
> > What you do need to do to reproduce the described problems is
> > check out the Postgres git tree and rewind to just before
> > commit 0b16bb877, where we deleted AIX support. Any attempt
> > to res
> What you do need to do to reproduce the described problems is
> check out the Postgres git tree and rewind to just before
> commit 0b16bb877, where we deleted AIX support. Any attempt
> to restore AIX support would have to start with reverting that
> commit (and perhaps the fol
Thomas Munro writes:
> Oh, sorry, I had missed the part where newer compilers fix the issue
> too. Old out-of-support versions of AIX running old compilers, what
> fun.
Indeed. One of the topics that needs investigation if you want to
pursue this is which AIX system and compiler versions still
On Fri, Mar 29, 2024 at 4:00 PM Thomas Munro wrote:
> On Fri, Mar 29, 2024 at 3:48 PM Noah Misch wrote:
> > The thread Alvaro and Tom cited contains an analysis. It's a compiler bug.
> > You can get past the compiler bug by upgrading your compiler; both ibm-clang
> > 17.1.1.2 and gcc 13.2.0 are
the Postgres git tree and rewind to just before
commit 0b16bb877, where we deleted AIX support. Any attempt
to restore AIX support would have to start with reverting that
commit (and perhaps the followup f0827b443).
regards, tom lane
On Fri, Mar 29, 2024 at 3:48 PM Noah Misch wrote:
> On Thu, Mar 28, 2024 at 11:09:43AM +, Sriram RK wrote:
> > We are setting up the build environment and trying to build the source and
> > also trying to analyze the assert from the Aix point of view.
>
> The thread Alvaro and Tom cited
On Thu, Mar 28, 2024 at 11:09:43AM +, Sriram RK wrote:
> We are setting up the build environment and trying to build the source and
> also trying to analyze the assert from the Aix point of view.
The thread Alvaro and Tom cited contains an analysis. It's a compiler bug.
You can get past the
ards,
Sriram.
> From: Sriram RK
> Date: Thursday, 21 March 2024 at 10:05 PM
> To: Tom Lane t...@sss.pgh.pa.us<mailto:t...@sss.pgh.pa.us>, Alvaro Herrera
> Cc: pgsql-hack...@postgresql.org<mailto:pgsql-hack...@postgresql.org>
> Subject: Re: AIX support
> Th
Thanks, Tom and Alvaro, for the info.
We shall look into to details and get back.
From: Tom Lane
Date: Thursday, 21 March 2024 at 7:27 PM
To: Sriram RK
Cc: pgsql-hack...@postgresql.org
Subject: Re: AIX support
Sriram RK writes:
> We are working on AIX systems and noticed that the thr
Sriram RK writes:
> We are working on AIX systems and noticed that the thread on removing AIX
> support in Postgres going forward.
> https://github.com/postgres/postgres/commit/0b16bb8776bb834eb1ef8204ca95dd7667ab948b
> We would be glad to understand any outstanding issu
On 2024-Mar-21, Sriram RK wrote:
> Hello Team,
>
> We are working on AIX systems and noticed that the thread on removing AIX
> support in Postgres going forward.
>
> https://github.com/postgres/postgres/commit/0b16bb8776bb834eb1ef8204ca95dd7667ab948b”
>
> We would b
Hello Team,
We are working on AIX systems and noticed that the thread on removing AIX
support in Postgres going forward.
https://github.com/postgres/postgres/commit/0b16bb8776bb834eb1ef8204ca95dd7667ab948b”
We would be glad to understand any outstanding issues hindering the support on
AIX
kers ; Melanie Plageman
Objet : Re: Remove AIX Support (was: Re: Relation bulk write facility)
Hi,
On 2024-02-29 10:24:24 +0100, Michael Banck wrote:
> On Thu, Feb 29, 2024 at 12:57:31AM -0800, Andres Freund wrote:
> > On 2024-02-29 09:13:04 +0100, Michael Banck wrote:
> > > T
> On 29 Feb 2024, at 10:24, Michael Banck wrote:
> On Thu, Feb 29, 2024 at 12:57:31AM -0800, Andres Freund wrote:
>> Then these users should have paid somebody to actually do maintenance work on
>> the AIX support,o it doesn't regularly stand in the way of implementing
and not as a
> > > thought-experiment. It is probably well-known among Postgres hackers
> > > that AIX support is problematic/a burden, but the current users might
> > > not be aware of this.
> >
> > Then these users should have paid somebody to act
t; or Irix, I believe Postgres on AIX is still used in production and if
> > so, probably in a mission-critical manner at some old-school
> > institutions (in fact, one of our customers does just that) and not as a
> > thought-experiment. It is probably well-known among Postgres hack
so, probably in a mission-critical manner at some old-school
> institutions (in fact, one of our customers does just that) and not as a
> thought-experiment. It is probably well-known among Postgres hackers
> that AIX support is problematic/a burden, but the current users might
> not be aware of
> On 29 Feb 2024, at 09:13, Michael Banck wrote:
> In any case, users will have a couple of years to migrate as usual if
> they upgrade to v16.
As you say, there are many years left of AIX being supported so there is plenty
of runway for planning a migration.
--
Daniel Gustafsson
thought-experiment. It is probably well-known among Postgres hackers
that AIX support is problematic/a burden, but the current users might
not be aware of this.
Not sure what to do about this (especially now that this has been
committed), maybe there should have been be a public deprecation n
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
> > 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=7u07tja59wt...@mail
each 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=7u07tja59wt...@mail.gmail.com
and discussion ensued from there. I agree that manually maintaining
alignment, even with a regre
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).
1 - 100 of 106 matches
Mail list logo
