public inbox for [email protected]
help / color / mirror / Atom feedRe: AIX support
33+ messages / 11 participants
[nested] [flat]
* Re: AIX support
@ 2024-03-29 03:14 Thomas Munro <[email protected]>
0 siblings, 1 reply; 33+ messages in thread
From: Thomas Munro @ 2024-03-29 03:14 UTC (permalink / raw)
To: Noah Misch <[email protected]>; +Cc: Sriram RK <[email protected]>; Tom Lane <[email protected]>; Alvaro Herrera <[email protected]>; pgsql-hackers
On Fri, Mar 29, 2024 at 4:00 PM Thomas Munro <[email protected]> wrote:
> On Fri, Mar 29, 2024 at 3:48 PM Noah Misch <[email protected]> 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 free from the bug.
>
> For the specific issue that triggered that, I strongly suspect that it
> would go away if we just used smgrzeroextend() instead of smgrextend()
> using that variable with the alignment requirement, since, as far as I
> can tell from build farm clues, the otherwise similar function-local
> static variable used by the former (ie one that the linker must still
> control the location of AFAIK?) seems to work fine.
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.
^ permalink raw reply [nested|flat] 33+ messages in thread
* Re: AIX support
@ 2024-03-29 03:33 Tom Lane <[email protected]>
parent: Thomas Munro <[email protected]>
0 siblings, 1 reply; 33+ messages in thread
From: Tom Lane @ 2024-03-29 03:33 UTC (permalink / raw)
To: Thomas Munro <[email protected]>; +Cc: Noah Misch <[email protected]>; Sriram RK <[email protected]>; Alvaro Herrera <[email protected]>; pgsql-hackers
Thomas Munro <[email protected]> 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 deserve
support, and which of the AIX hacks we had been carrying still need
to be there based on that analysis. For context, we've been pruning
support for extinct-in-the-wild OS versions pretty aggressively
over the past couple of years, and I'd expect to apply the same
standard to AIX.
regards, tom lane
^ permalink raw reply [nested|flat] 33+ messages in thread
* Re: AIX support
@ 2024-04-05 16:12 Sriram RK <[email protected]>
parent: Tom Lane <[email protected]>
0 siblings, 1 reply; 33+ messages in thread
From: Sriram RK @ 2024-04-05 16:12 UTC (permalink / raw)
To: Tom Lane <[email protected]>; Thomas Munro <[email protected]>; Alvaro Herrera <[email protected]>; Noah Misch <[email protected]>; +Cc: pgsql-hackers
> 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 followup f0827b443).
> regards, tom lane
Hi Team, thank you for all the info.
We progressed to build the source on our nodes and the build was successful with the below configuration.
Postgres - github-bcdfa5f2e2f
AIX - 71c
Xlc - 13.1.0
Bison - 3.0.5
Going ahead, we want to build the changes that were removed as part of “0b16bb8776bb8”, with latest Xlc and gcc version.
We were building the source from the postgres ftp server(https://ftp.postgresql.org/pub/source/), would like to understand if there are any source level changes between the ftp server and the source on github?
Regards,
Sriram.
From: Tom Lane <[email protected]>
Date: Friday, 29 March 2024 at 9:03 AM
To: Thomas Munro <[email protected]>
Cc: Noah Misch <[email protected]>, Sriram RK <[email protected]>, Alvaro Herrera <[email protected]>, [email protected] <[email protected]>
Subject: Re: AIX support
Thomas Munro <[email protected]> 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 deserve
support, and which of the AIX hacks we had been carrying still need
to be there based on that analysis. For context, we've been pruning
support for extinct-in-the-wild OS versions pretty aggressively
over the past couple of years, and I'd expect to apply the same
standard to AIX.
regards, tom lane
^ permalink raw reply [nested|flat] 33+ messages in thread
* Re: AIX support
@ 2024-04-05 17:26 Noah Misch <[email protected]>
parent: Sriram RK <[email protected]>
0 siblings, 1 reply; 33+ messages in thread
From: Noah Misch @ 2024-04-05 17:26 UTC (permalink / raw)
To: Sriram RK <[email protected]>; +Cc: Tom Lane <[email protected]>; Thomas Munro <[email protected]>; Alvaro Herrera <[email protected]>; pgsql-hackers
On Fri, Apr 05, 2024 at 04:12:06PM +0000, 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 restore AIX support would have to start with reverting that
> > commit (and perhaps the followup f0827b443).
> Going ahead, we want to build the changes that were removed as part of “0b16bb8776bb8”, with latest Xlc and gcc version.
>
> We were building the source from the postgres ftp server(https://ftp.postgresql.org/pub/source/), would like to understand if there are any source level changes between the ftp server and the source on github?
To succeed in this endeavor, you'll need to develop fluency in the tools to
answer questions like that, or bring in someone who is fluent. In this case,
GNU diff is the standard tool for answering your question. These resources
cover other topics you would need to learn:
https://wiki.postgresql.org/wiki/Developer_FAQ
https://wiki.postgresql.org/wiki/So,_you_want_to_be_a_developer%3F
^ permalink raw reply [nested|flat] 33+ messages in thread
* Re: AIX support
@ 2024-04-18 11:15 Sriram RK <[email protected]>
parent: Noah Misch <[email protected]>
0 siblings, 2 replies; 33+ messages in thread
From: Sriram RK @ 2024-04-18 11:15 UTC (permalink / raw)
To: Noah Misch <[email protected]>; Tom Lane <[email protected]>; Thomas Munro <[email protected]>; Alvaro Herrera <[email protected]>; +Cc: pgsql-hackers; [email protected] <[email protected]>
Thanks Noah and Team,
We (IBM-AIX team) looked into this issue
https://www.postgresql.org/message-id/[email protected]
This is related to the compiler issue. The compilers xlc(13.1) and gcc(8.0) have issues. But we verified that this issue is resolved with the newer compiler versions openXL(xlc17.1) and gcc(12.0) onwards.
We reported this issue to the xlc team and they have noted this issue. A fix might be possible in May for this issue in xlc v16. We would like to understand if the community can start using the latest compilers to build the source.
Also as part 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 that postgres is used extensively in our IBM product and is being exploited by multiple customers.
Please let us know if there are any specific details you'd like to discuss further.
Regards,
Sriram.
^ permalink raw reply [nested|flat] 33+ messages in thread
* Re: AIX support
@ 2024-04-18 11:25 Heikki Linnakangas <[email protected]>
parent: Sriram RK <[email protected]>
1 sibling, 1 reply; 33+ messages in thread
From: Heikki Linnakangas @ 2024-04-18 11:25 UTC (permalink / raw)
To: [email protected]; Sriram RK <[email protected]>; Noah Misch <[email protected]>; Tom Lane <[email protected]>; Thomas Munro <[email protected]>; Alvaro Herrera <[email protected]>; +Cc: pgsql-hackers; [email protected] <[email protected]>
On 18 April 2024 14:15:43 GMT+03:00, Sriram RK <[email protected]> wrote:
>Thanks Noah and Team,
>
>We (IBM-AIX team) looked into this issue
>
>https://www.postgresql.org/message-id/[email protected]
>
>This is related to the compiler issue. The compilers xlc(13.1) and gcc(8.0) have issues. But we verified that this issue is resolved with the newer compiler versions openXL(xlc17.1) and gcc(12.0) onwards.
>
>We reported this issue to the xlc team and they have noted this issue. A fix might be possible in May for this issue in xlc v16. We would like to understand if the community can start using the latest compilers to build the source.
>
>Also as part 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.
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.
>We want to make a note that postgres is used extensively in our IBM product and is being exploited by multiple customers.
Noted. I'm glad to hear you are interested to put in some effort for this. The situation from the current maintainers is that none of us have much interest, or resources or knowledge to keep the AIX build working, so we'll definitely need the help.
No promises on v17, but let's at least make sure the stable branches keep working. And with the patches and buildfarm support from you, maybe v17 is feasible too.
- Heikki
^ permalink raw reply [nested|flat] 33+ messages in thread
* Re: AIX support
@ 2024-04-18 11:57 Sriram RK <[email protected]>
parent: Heikki Linnakangas <[email protected]>
0 siblings, 0 replies; 33+ messages in thread
From: Sriram RK @ 2024-04-18 11:57 UTC (permalink / raw)
To: Heikki Linnakangas <[email protected]>; [email protected] <[email protected]>; Noah Misch <[email protected]>; Tom Lane <[email protected]>; Thomas Munro <[email protected]>; Alvaro Herrera <[email protected]>; +Cc: pgsql-hackers; [email protected] <[email protected]>
> 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+ bcdfa5f2e2f) on our local nodes. We will try to setup the buildfarm and let you know.
Is there any specific configuration we are looking for?
Regards,
Sriram.
^ permalink raw reply [nested|flat] 33+ messages in thread
* Re: AIX support
@ 2024-04-18 18:01 Andres Freund <[email protected]>
parent: Sriram RK <[email protected]>
1 sibling, 2 replies; 33+ messages in thread
From: Andres Freund @ 2024-04-18 18:01 UTC (permalink / raw)
To: Sriram RK <[email protected]>; +Cc: Noah Misch <[email protected]>; Tom Lane <[email protected]>; Thomas Munro <[email protected]>; Alvaro Herrera <[email protected]>; pgsql-hackers; [email protected] <[email protected]>
Hi,
On 2024-04-18 11:15:43 +0000, Sriram RK wrote:
> We (IBM-AIX team) looked into this issue
>
> https://www.postgresql.org/message-id/[email protected]
>
> This is related to the compiler issue. The compilers xlc(13.1) and gcc(8.0)
> have issues. But we verified that this issue is resolved with the newer
> compiler versions openXL(xlc17.1) and gcc(12.0) onwards.
The reason we used these compilers was that those were the only ones we had
kinda somewhat reasonable access to, via the gcc projects'
"compile farm" https://portal.cfarm.net/
We have 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 VM within a few minutes and iron out whatever
portability issue I'm dealing with.
Not being AIX customers we also can't raise bugs about compiler bugs, so we're
stuck doing bad workarounds.
> Also as part 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.
The state when was removed was not in a state that I am OK with adding back.
> We want to make a note that postgres is used extensively in our IBM product
> and is being exploited by multiple customers.
To be blunt: Then it'd have been nice to see some investment in that before
now. Both on the code level and the infrastructure level (i.e. access to
machines etc).
Greetings,
Andres Freund
^ permalink raw reply [nested|flat] 33+ messages in thread
* Re: AIX support
@ 2024-04-19 00:40 Thomas Munro <[email protected]>
parent: Andres Freund <[email protected]>
1 sibling, 0 replies; 33+ messages in thread
From: Thomas Munro @ 2024-04-19 00:40 UTC (permalink / raw)
To: Andres Freund <[email protected]>; +Cc: Sriram RK <[email protected]>; Noah Misch <[email protected]>; Tom Lane <[email protected]>; Alvaro Herrera <[email protected]>; pgsql-hackers; [email protected] <[email protected]>
On Fri, Apr 19, 2024 at 6:01 AM Andres Freund <[email protected]> wrote:
> On 2024-04-18 11:15:43 +0000, Sriram RK wrote:
> > We (IBM-AIX team) looked into this issue
> >
> > https://www.postgresql.org/message-id/[email protected]
> >
> > This is related to the compiler issue. The compilers xlc(13.1) and gcc(8.0)
> > have issues. But we verified that this issue is resolved with the newer
> > compiler versions openXL(xlc17.1) and gcc(12.0) onwards.
>
> The reason we used these compilers was that those were the only ones we had
> kinda somewhat reasonable access to, via the gcc projects'
> "compile farm" https://portal.cfarm.net/
> We have to rely on whatever the aix machines there provide. They're not
> particularly plentiful resource-wise either.
To be fair, those OSUOSL machines are donated by IBM:
https://osuosl.org/services/powerdev/
It's just that they seem to be mostly focused on supporting Linux on
POWER, with only a couple of AIX hosts (partitions/virtual machines?)
made available via portal.cfarm.net, and they only very recently added
a modern AIX 7.3 host. That's cfarm119, upgraded in September-ish,
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 within a few minutes and iron out whatever
> portability issue I'm dealing with.
Yeah. It is a known secret that you can run AIX inside Qemu/kvm (it
appears that IBM has made changes to it to make that possible, because
earlier AIX versions didn't like Qemu's POWER emulation or
virtualisation, there are blog posts about it), but IBM doesn't
actually make the images available to non-POWER-hardware owners (you
need a serial number). If I were an OS vendor and wanted developers
to target my OS for free, at the very top of my TODO list I would
have: provide an easy to use image for developers to be able to spin
something up in minutes and possibly even use in CI systems. That's
the reason I can fix any minor portability issue on Linux, illumos,
*BSD quickly and Windows with only moderate extra pain. Even Oracle
knows this, see Solaris CBE.
> > We want to make a note that postgres is used extensively in our IBM product
> > and is being exploited by multiple customers.
>
> To be blunt: Then it'd have been nice to see some investment in that before
> now. Both on the code level and the infrastructure level (i.e. access to
> machines etc).
In the AIX space generally, there were even clues that funding had
been completely cut even for packaging PostgreSQL. I was aware of two
packaging projects (not sure how they were related):
1. The ATOS packaging group, who used to show up on our mailing lists
and discuss code changes, which announced it was shutting down:
https://github.com/power-devops/bullfreeware
2. And last time I looked a few months back, the IBM AIX Toolbox
packaging project only had PostgreSQL 10 or 11 packages, already out
of support by us, meaning that their maintainer had given up, too:
https://www.ibm.com/support/pages/aix-toolbox-open-source-software-downloads-alpha
However I see that recently (last month?) someone has added PostgreSQL
15, so something has only just reawoken there?
There are quite a lot of threads about AIX problems, but they are
almost all just us non-AIX-users trying to unbreak stupid stuff on the
build farm, which at some points began to seem distinctly quixotic:
chivalric hackers valiantly trying to keep the entire Unix family tree
working even though we don't remember why and th versions involved are
out of support even by the vendor. Of the three old giant commercial
Unixes, HP-UX was dropped without another mention (it really was a
windmill after all), Solaris is somehow easier to deal with (I could
guess it's because it influenced Linux and BSD so much, ELF and linker
details spring to mind), while AIX fails on every dimension:
unrepresented by users, lacking in build farm, unavailable to
non-customers, and unusual among Unixen.
^ permalink raw reply [nested|flat] 33+ messages in thread
* Re: AIX support
@ 2024-04-19 11:04 Sriram RK <[email protected]>
parent: Andres Freund <[email protected]>
1 sibling, 1 reply; 33+ messages in thread
From: Sriram RK @ 2024-04-19 11:04 UTC (permalink / raw)
To: Andres Freund <[email protected]>; Thomas Munro <[email protected]>; +Cc: Noah Misch <[email protected]>; Tom Lane <[email protected]>; Alvaro Herrera <[email protected]>; pgsql-hackers; [email protected] <[email protected]>; Heikki Linnakangas <[email protected]>
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.
^ permalink raw reply [nested|flat] 33+ messages in thread
* Re: AIX support
@ 2024-04-20 15:42 Peter Eisentraut <[email protected]>
parent: Sriram RK <[email protected]>
0 siblings, 2 replies; 33+ messages in thread
From: Peter Eisentraut @ 2024-04-20 15:42 UTC (permalink / raw)
To: Sriram RK <[email protected]>; Andres Freund <[email protected]>; Thomas Munro <[email protected]>; +Cc: Noah Misch <[email protected]>; Tom Lane <[email protected]>; Alvaro Herrera <[email protected]>; pgsql-hackers; [email protected] <[email protected]>; Heikki Linnakangas <[email protected]>
On 19.04.24 13:04, Sriram RK wrote:
> 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.
I think we should manage expectations here, if there is any hope of
getting 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 timely and fair.
But the underlying issue that led to the removal (something to do with
direct I/O support and alignment) would still need to be addressed. And
this probably wouldn't just need some infrastructure support; it would
require contributions from someone who actively knows how to develop on
this platform. Now, direct I/O is currently sort of an experimental
feature, so disabling it on AIX, as was initially suggested in that
discussion, might be okay for now, but the issue will come up again.
Even if this new buildfarm support is forthcoming, there has to be some
sort of deadline in any resurrection attempts for PG17. The first beta
date has been set for 23 May. If we are making the reinstatement of AIX
support contingent on new buildfarm support, those machines need to be
available, at least initially, at least for backbranches, like in a
week. Which seems tight.
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 change.)
2. Like (1), but we consider that notice has been given, and we will
remove it early in PG18 (like August) unless the situation improves.
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 over the years in the old port. Another looming issue is
that the meson build system only supported AIX with gcc before the
removal. I don't know what it would take to expand that to support
xclang, but if it requires meson upstream work, you have that to do, too.
^ permalink raw reply [nested|flat] 33+ messages in thread
* Re: AIX support
@ 2024-04-20 16:25 Tom Lane <[email protected]>
parent: Peter Eisentraut <[email protected]>
1 sibling, 2 replies; 33+ messages in thread
From: Tom Lane @ 2024-04-20 16:25 UTC (permalink / raw)
To: Peter Eisentraut <[email protected]>; +Cc: Sriram RK <[email protected]>; Andres Freund <[email protected]>; Thomas Munro <[email protected]>; Noah Misch <[email protected]>; Alvaro Herrera <[email protected]>; pgsql-hackers; [email protected] <[email protected]>; Heikki Linnakangas <[email protected]>
Peter Eisentraut <[email protected]> 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 using that" is timely and fair.
Yup, that's a totally fair complaint. Still ...
> 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 change.)
> 2. Like (1), but we consider that notice has been given, and we will
> remove it early in PG18 (like August) unless the situation improves.
> 3. We leave it out of PG17 and consider a new AIX port for PG18 on its
> own merits.
Andres has ably summarized the reasons why the status quo ante was
getting untenable. The direct-I/O problem could have been tolerable
on its own, but in reality it was the straw that broke the camel's
back so far as our willingness to maintain AIX support went. There
were just too many hacks and workarounds for too many problems,
with too few people interested in looking for better answers.
So I'm totally not in favor of #1, at least not without some hard
commitments and follow-through on really cleaning up the mess
(which maybe looks more like your #2). What's needed here, as
you said, is for someone with a decent amount of expertise in
modern AIX to review all the issues. Maybe framing that as a
"new port" per #3 would be a good way to think about it. But
I don't want 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 how many of the hacks removed in 0b16bb877 really need to be put
back, versus being obsolete or amenable to a nicer solution in
late-model AIX. If we take a "new port" mindset then it would be
totally reasonable to say that it only supports very recent AIX
releases, so I'd hope at least some of the cruft could be removed.
regards, tom lane
^ permalink raw reply [nested|flat] 33+ messages in thread
* Re: AIX support
@ 2024-04-22 10:12 Sriram RK <[email protected]>
parent: Tom Lane <[email protected]>
1 sibling, 0 replies; 33+ messages in thread
From: Sriram RK @ 2024-04-22 10:12 UTC (permalink / raw)
To: Tom Lane <[email protected]>; Peter Eisentraut <[email protected]>; +Cc: Andres Freund <[email protected]>; Thomas Munro <[email protected]>; Noah Misch <[email protected]>; Alvaro Herrera <[email protected]>; pgsql-hackers; [email protected] <[email protected]>; Heikki Linnakangas <[email protected]>
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 timely and fair.
We would really like to thank you & the team for considering our request,
and really appreciate for providing all the possible options to support AIX.
> But the underlying issue that led to the removal (something to do with
> direct I/O support and alignment) would still need to be addressed.
As we already validated that these alignment specific issues are resolved
with the latest versions of the compilers (gcc/ibm-clang). We would request
you to use the latest versions for the build.
> If we are making the reinstatement of AIX
> support contingent on new buildfarm support, those machines need to be
> available, at least initially, at least for back branches, like in a
> week. Which seems tight.
We are already working with the internal team in procuring the nodes
for the buildfarm, which can be accessible by the community.
> 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 change.)
> 2. Like (1), but we consider that notice has been given, and we will
> remove it early in PG18 (like August) unless the situation improves.
We would really appreciate you for providing the possible options
and we are very much inclined to these above approaches.
Regards,
Sriram.
^ permalink raw reply [nested|flat] 33+ messages in thread
* Re: AIX support
@ 2024-04-22 14:54 Tristan Partin <[email protected]>
parent: Peter Eisentraut <[email protected]>
1 sibling, 0 replies; 33+ messages in thread
From: Tristan Partin @ 2024-04-22 14:54 UTC (permalink / raw)
To: Peter Eisentraut <[email protected]>; Sriram RK <[email protected]>; +Cc: Noah Misch <[email protected]>; Tom Lane <[email protected]>; Alvaro Herrera <[email protected]>; pgsql-hackers; [email protected] <[email protected]>; Andres Freund <[email protected]>; Thomas Munro <[email protected]>; Heikki Linnakangas <[email protected]>
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 over the years in the old port. Another looming issue is
> that the meson build system only supported AIX with gcc before the
> removal. I don't know what it would take to expand that to support
> xclang, but if it requires meson upstream work, you have that to do, too.
Happy to help advocate for any PRs from AIX folks on the Meson side. You
can find me as @tristan957 on github.
--
Tristan Partin
Neon (https://neon.tech)
^ permalink raw reply [nested|flat] 33+ messages in thread
* Re: AIX support
@ 2024-04-25 03:39 Bruce Momjian <[email protected]>
parent: Tom Lane <[email protected]>
1 sibling, 1 reply; 33+ messages in thread
From: Bruce Momjian @ 2024-04-25 03:39 UTC (permalink / raw)
To: Tom Lane <[email protected]>; +Cc: Peter Eisentraut <[email protected]>; Sriram RK <[email protected]>; Andres Freund <[email protected]>; Thomas Munro <[email protected]>; Noah Misch <[email protected]>; Alvaro Herrera <[email protected]>; pgsql-hackers; [email protected] <[email protected]>; Heikki Linnakangas <[email protected]>
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 change.)
> > 2. Like (1), but we consider that notice has been given, and we will
> > remove it early in PG18 (like August) unless the situation improves.
> > 3. We leave it out of PG17 and consider a new AIX port for PG18 on its
> > own merits.
>
> Andres has ably summarized the reasons why the status quo ante was
> getting untenable. The direct-I/O problem could have been tolerable
> on its own, but in reality it was the straw that broke the camel's
> back so far as our willingness to maintain AIX support went. There
> were just too many hacks and workarounds for too many problems,
> with too few people interested in looking for better answers.
>
> So I'm totally not in favor of #1, at least not without some hard
> commitments and follow-through on really cleaning up the mess
> (which maybe looks more like your #2). What's needed here, as
> you said, is for someone with a decent amount of expertise in
> modern AIX to review all the issues. Maybe framing that as a
> "new port" per #3 would be a good way to think about it. But
> I don't want 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 how many of the hacks removed in 0b16bb877 really need to be put
> back, versus being obsolete or amenable to a nicer solution in
> late-model AIX. If we take a "new port" mindset then it would be
> totally reasonable to say that it only supports very recent AIX
> releases, so I'd hope at least some of the cruft could be removed.
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 with too little support.
--
Bruce Momjian <[email protected]> https://momjian.us
EDB https://enterprisedb.com
Only you can decide what is important to you.
^ permalink raw reply [nested|flat] 33+ messages in thread
* Re: AIX support
@ 2024-04-25 04:06 Michael Paquier <[email protected]>
parent: Bruce Momjian <[email protected]>
0 siblings, 2 replies; 33+ messages in thread
From: Michael Paquier @ 2024-04-25 04:06 UTC (permalink / raw)
To: Bruce Momjian <[email protected]>; +Cc: Tom Lane <[email protected]>; Peter Eisentraut <[email protected]>; Sriram RK <[email protected]>; Andres Freund <[email protected]>; Thomas Munro <[email protected]>; Noah Misch <[email protected]>; Alvaro Herrera <[email protected]>; pgsql-hackers; [email protected] <[email protected]>; Heikki Linnakangas <[email protected]>
On Wed, Apr 24, 2024 at 11:39:37PM -0400, Bruce Momjian wrote:
> On Sat, Apr 20, 2024 at 12:25:47PM -0400, Tom Lane wrote:
>> So I'm totally not in favor of #1, at least not without some hard
>> commitments and follow-through on really cleaning up the mess
>> (which maybe looks more like your #2). What's needed here, as
>> you said, is for someone with a decent amount of expertise in
>> modern AIX to review all the issues. Maybe framing that as a
>> "new port" per #3 would be a good way to think about it. But
>> I don't want 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 how many of the hacks removed in 0b16bb877 really need to be put
>> back, versus being obsolete or amenable to a nicer solution in
>> late-model AIX. If we take a "new port" mindset then it would be
>> totally reasonable to say that it only supports very recent AIX
>> releases, so I'd hope at least some of the cruft could be removed.
>
> 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 with too little support.
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 supported
base. I'd like to think backporting these to stable branches should
be OK at some point, once the new port is proving baked enough.
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 environments would help a lot. Overall,
studying that afresh with v18 looks like a good idea, assuming that
anybody who commits such patches has access to hosts to evaluate them,
with buildfarm members running on top, of course.
My 2c.
--
Michael
Attachments:
[application/pgp-signature] signature.asc (833B, 2-signature.asc)
download
^ permalink raw reply [nested|flat] 33+ messages in thread
* Re: AIX support
@ 2024-04-25 04:20 Tom Lane <[email protected]>
parent: Michael Paquier <[email protected]>
1 sibling, 2 replies; 33+ messages in thread
From: Tom Lane @ 2024-04-25 04:20 UTC (permalink / raw)
To: Michael Paquier <[email protected]>; +Cc: Bruce Momjian <[email protected]>; Peter Eisentraut <[email protected]>; Sriram RK <[email protected]>; Andres Freund <[email protected]>; Thomas Munro <[email protected]>; Noah Misch <[email protected]>; Alvaro Herrera <[email protected]>; pgsql-hackers; [email protected] <[email protected]>; Heikki Linnakangas <[email protected]>
Michael Paquier <[email protected]> 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 supported
> base.
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
their database server was built with. On the other hand, I'm a strong
proponent of avoiding software monocultures, and xlc is one of the few
C compilers still standing that aren't gcc or clang.
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.
> I'd like to think backporting these to stable branches should
> be OK at some point, once the new port is proving baked enough.
If things go as I expect, the "new port" would effectively drop
support for older AIX and/or older compiler versions. So back-
porting seems like an unlikely decision.
> 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.
+many
regards, tom lane
^ permalink raw reply [nested|flat] 33+ messages in thread
* Re: AIX support
@ 2024-04-25 04:45 Michael Paquier <[email protected]>
parent: Tom Lane <[email protected]>
1 sibling, 1 reply; 33+ messages in thread
From: Michael Paquier @ 2024-04-25 04:45 UTC (permalink / raw)
To: Tom Lane <[email protected]>; +Cc: Bruce Momjian <[email protected]>; Peter Eisentraut <[email protected]>; Sriram RK <[email protected]>; Andres Freund <[email protected]>; Thomas Munro <[email protected]>; Noah Misch <[email protected]>; Alvaro Herrera <[email protected]>; pgsql-hackers; [email protected] <[email protected]>; Heikki Linnakangas <[email protected]>
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 of the interest is in xlc, not gcc. But I
may be wrong.
Saying that, dividing the effort into more successive steps is
sensible here (didn't consider that previously, you have a good
point).
--
Michael
Attachments:
[application/pgp-signature] signature.asc (833B, 2-signature.asc)
download
^ permalink raw reply [nested|flat] 33+ messages in thread
* Re: AIX support
@ 2024-04-25 08:03 Peter Eisentraut <[email protected]>
parent: Tom Lane <[email protected]>
1 sibling, 1 reply; 33+ messages in thread
From: Peter Eisentraut @ 2024-04-25 08:03 UTC (permalink / raw)
To: Tom Lane <[email protected]>; Michael Paquier <[email protected]>; +Cc: Bruce Momjian <[email protected]>; Sriram RK <[email protected]>; Andres Freund <[email protected]>; Thomas Munro <[email protected]>; Noah Misch <[email protected]>; Alvaro Herrera <[email protected]>; pgsql-hackers; [email protected] <[email protected]>; Heikki Linnakangas <[email protected]>
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
> their database server was built with. On the other hand, I'm a strong
> proponent of avoiding software monocultures, and xlc is one of the few
> C compilers still standing that aren't gcc or clang.
My understanding is that the old xlc is dead and has been replaced by
"xlclang", which is presumably an xlc-compatible frontend on top of
clang/llvm. Hopefully, that will have fewer issues.
^ permalink raw reply [nested|flat] 33+ messages in thread
* Re: AIX support
@ 2024-04-25 13:54 Tom Lane <[email protected]>
parent: Peter Eisentraut <[email protected]>
0 siblings, 0 replies; 33+ messages in thread
From: Tom Lane @ 2024-04-25 13:54 UTC (permalink / raw)
To: Peter Eisentraut <[email protected]>; +Cc: Michael Paquier <[email protected]>; Bruce Momjian <[email protected]>; Sriram RK <[email protected]>; Andres Freund <[email protected]>; Thomas Munro <[email protected]>; Noah Misch <[email protected]>; Alvaro Herrera <[email protected]>; pgsql-hackers; [email protected] <[email protected]>; Heikki Linnakangas <[email protected]>
Peter Eisentraut <[email protected]> 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 an xlc-compatible frontend on top of
> clang/llvm. Hopefully, that will have fewer issues.
[ googles... ] Actually it seems to be the other way around:
per [1] xlclang is a clang-based front end to IBM's existing
codegen+optimization logic, and the xlc front end is still there too.
It's not at all clear that they have any intention of killing off xlc.
Not sure where that leaves us in terms of either one being an
interesting target to support. xlclang is presumably an easier lift
to get working, but that also makes it much less interesting from
the preserve-our-portability standpoint.
regards, tom lane
[1] https://www.ibm.com/docs/en/xl-c-and-cpp-aix/16.1?topic=new-clang-based-front-end
^ permalink raw reply [nested|flat] 33+ messages in thread
* Re: AIX support
@ 2024-04-26 17:06 Bruce Momjian <[email protected]>
parent: Michael Paquier <[email protected]>
1 sibling, 0 replies; 33+ messages in thread
From: Bruce Momjian @ 2024-04-26 17:06 UTC (permalink / raw)
To: Michael Paquier <[email protected]>; +Cc: Tom Lane <[email protected]>; Peter Eisentraut <[email protected]>; Sriram RK <[email protected]>; Andres Freund <[email protected]>; Thomas Munro <[email protected]>; Noah Misch <[email protected]>; Alvaro Herrera <[email protected]>; pgsql-hackers; [email protected] <[email protected]>; Heikki Linnakangas <[email protected]>
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 environments would help a lot. Overall,
> studying that afresh with v18 looks like a good idea, assuming that
> anybody who commits such patches has access to hosts to evaluate them,
> with buildfarm members running on top, of course.
Agreed. They can't even have buildfarm member for PG 17 since it
doesn't compile anymore, so someone has to go over the reverted patch,
figure out which ones are still valid, and report back. Trying to add a
port, with possible breakage, during beta seems too risky compared to
the value.
--
Bruce Momjian <[email protected]> https://momjian.us
EDB https://enterprisedb.com
Only you can decide what is important to you.
^ permalink raw reply [nested|flat] 33+ messages in thread
* Re: AIX support
@ 2024-04-26 17:30 Sriram RK <[email protected]>
parent: Michael Paquier <[email protected]>
0 siblings, 1 reply; 33+ messages in thread
From: Sriram RK @ 2024-04-26 17:30 UTC (permalink / raw)
To: Michael Paquier <[email protected]>; Tom Lane <[email protected]>; +Cc: Bruce Momjian <[email protected]>; Peter Eisentraut <[email protected]>; Andres Freund <[email protected]>; Thomas Munro <[email protected]>; Noah Misch <[email protected]>; Alvaro Herrera <[email protected]>; pgsql-hackers; [email protected] <[email protected]>; Heikki Linnakangas <[email protected]>
> > 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
> may be wrong.
Just a heads-up, we got a node in the OSU lab for the buildfarm. Will let you know once we have the buildfarm setup on that node.
Also, we are making progress on setting up the buildfarm on a local node as well.
But currently there are some tests failing, seems some issue with plperl.
aix01::build-farm-17#
./run_build.pl --keepall --nosend --nostatus --verbose=5 --force REL_16_STABLE
Fri Apr 26 00:53:50 2024: buildfarm run for AIXnode01:REL_16_STABLE starting
AIXnode01:REL_16_STABLE [00:53:50] checking out source ...
AIXnode01:REL_16_STABLE [00:53:56] checking if build run needed ...
AIXnode01:REL_16_STABLE [00:53:56] copying source to pgsql.build ...
AIXnode01:REL_16_STABLE [00:54:08] running configure ...
AIXnode01:REL_16_STABLE [00:55:01] running build ...
AIXnode01:REL_16_STABLE [01:08:09] running basic regression tests ...
AIXnode01:REL_16_STABLE [01:09:51] running make contrib ...
AIXnode01:REL_16_STABLE [01:11:08] running make testmodules ...
AIXnode01:REL_16_STABLE [01:11:19] running install ...
AIXnode01:REL_16_STABLE [01:11:48] running make contrib install ...
AIXnode01:REL_16_STABLE [01:12:01] running testmodules install ...
AIXnode01:REL_16_STABLE [01:12:06] checking test-decoding
gmake: gcc: A file or directory in the path name does not exist.
AIXnode01:REL_16_STABLE [01:12:28] running make check miscellaneous modules ...
gmake: gcc: A file or directory in the path name does not exist.
AIXnode01:REL_16_STABLE [01:13:50] setting up db cluster (C)...
AIXnode01:REL_16_STABLE [01:13:53] starting db (C)...
AIXnode01:REL_16_STABLE [01:13:53] running installcheck (C)...
AIXnode01:REL_16_STABLE [01:15:05] restarting db (C)...
AIXnode01:REL_16_STABLE [01:15:07] running make isolation check ...
AIXnode01:REL_16_STABLE [01:15:51] restarting db (C)...
AIXnode01:REL_16_STABLE [01:15:56] running make PL installcheck (C)...
Branch: REL_16_STABLE
Stage PLCheck-C failed with status 2
^ permalink raw reply [nested|flat] 33+ messages in thread
* Re: AIX support
@ 2024-05-04 16:01 Sriram RK <[email protected]>
parent: Sriram RK <[email protected]>
0 siblings, 1 reply; 33+ messages in thread
From: Sriram RK @ 2024-05-04 16:01 UTC (permalink / raw)
To: Michael Paquier <[email protected]>; Tom Lane <[email protected]>; Noah Misch <[email protected]>; +Cc: Bruce Momjian <[email protected]>; Peter Eisentraut <[email protected]>; Andres Freund <[email protected]>; Thomas Munro <[email protected]>; Alvaro Herrera <[email protected]>; pgsql-hackers; [email protected] <[email protected]>; Heikki Linnakangas <[email protected]>
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
an issue with the plperl extension. In the logs we noticed that when the
plperl extension is being created, it is failing to load the perl library.
- CREATE EXTENSION plperlu;
+ server closed the connection unexpectedly
+ This probably means the server terminated abnormally
+ before or while processing the request.
+ connection to server was lost
In the logfile we could see these
2024-05-04 05:05:17.537 CDT [3997786:17] pg_regress/plperl_setup LOG: statement: CREATE EXTENSION plperl;
Util.c: loadable library and perl binaries are mismatched (got first handshake key 9b80080, needed 9a80080)
We tried to resolve some of the suggestions mentioned here, but things couldn’t resolve.
https://www.postgresql.org/message-id/CALDaNm15qaRFb3WiPFAdFqoB9pj1E5SCPPUGB%2BnJ4iF4gXO6Rw%40mail.g...
Any inputs here would be greatly appreciated.
Regards,
Sriram.
^ permalink raw reply [nested|flat] 33+ messages in thread
* Re: AIX support
@ 2024-05-06 14:12 Sriram RK <[email protected]>
parent: Sriram RK <[email protected]>
0 siblings, 1 reply; 33+ messages in thread
From: Sriram RK @ 2024-05-06 14:12 UTC (permalink / raw)
To: Michael Paquier <[email protected]>; Tom Lane <[email protected]>; Noah Misch <[email protected]>; pgsql-hackers; +Cc: Bruce Momjian <[email protected]>; Peter Eisentraut <[email protected]>; Andres Freund <[email protected]>; Thomas Munro <[email protected]>; Alvaro Herrera <[email protected]>; [email protected] <[email protected]>; Heikki Linnakangas <[email protected]>
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 node.
p9aix (OSU)
OS: AIX 72Z
RELEASE 16
p9aix:REL_16_STABLE [08:31:26] OK
======== log passed to send_result ===========
Branch: REL_16_STABLE
All stages succeeded
RELEASE 15
p9aix:REL_15_STABLE [08:55:37] OK
======== log passed to send_result ===========
Branch: REL_15_STABLE
All stages succeeded
Also, we had successfully built release 16 branch on our local nodes as well
OS: AIX 71C
pgsql-aix71C:REL_16_STABLE [02:25:32] OK
======== log passed to send_result ===========
Branch: REL_16_STABLE
All stages succeeded
OS: AIX72Z
pgsql-aix72Z:REL_16_STABLE [02:35:03] OK
======== log passed to send_result ===========
Branch: REL_16_STABLE
All stages succeeded
OS: AIX73D
pgsql-aix73D:REL_16_STABLE [05:32:29] OK
======== log passed to send_result ===========
Branch: REL_16_STABLE
All stages succeeded
Regards,
Sriram.
^ permalink raw reply [nested|flat] 33+ messages in thread
* Re: AIX support
@ 2024-05-08 11:39 Sriram RK <[email protected]>
parent: Sriram RK <[email protected]>
0 siblings, 1 reply; 33+ messages in thread
From: Sriram RK @ 2024-05-08 11:39 UTC (permalink / raw)
To: Michael Paquier <[email protected]>; Tom Lane <[email protected]>; Noah Misch <[email protected]>; pgsql-hackers; +Cc: Bruce Momjian <[email protected]>; Peter Eisentraut <[email protected]>; Andres Freund <[email protected]>; Thomas Munro <[email protected]>; Alvaro Herrera <[email protected]>; [email protected] <[email protected]>; Heikki Linnakangas <[email protected]>
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.
^ permalink raw reply [nested|flat] 33+ messages in thread
* Re: AIX support
@ 2024-05-08 13:44 Peter Eisentraut <[email protected]>
parent: Sriram RK <[email protected]>
0 siblings, 1 reply; 33+ messages in thread
From: Peter Eisentraut @ 2024-05-08 13:44 UTC (permalink / raw)
To: Sriram RK <[email protected]>; Michael Paquier <[email protected]>; Tom Lane <[email protected]>; Noah Misch <[email protected]>; pgsql-hackers; +Cc: Bruce Momjian <[email protected]>; Andres Freund <[email protected]>; Thomas Munro <[email protected]>; Alvaro Herrera <[email protected]>; [email protected] <[email protected]>; Heikki Linnakangas <[email protected]>
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.
^ permalink raw reply [nested|flat] 33+ messages in thread
* Re: AIX support
@ 2024-05-08 14:06 Bruce Momjian <[email protected]>
parent: Peter Eisentraut <[email protected]>
0 siblings, 1 reply; 33+ messages in thread
From: Bruce Momjian @ 2024-05-08 14:06 UTC (permalink / raw)
To: Peter Eisentraut <[email protected]>; +Cc: Sriram RK <[email protected]>; Michael Paquier <[email protected]>; Tom Lane <[email protected]>; Noah Misch <[email protected]>; pgsql-hackers; Andres Freund <[email protected]>; Thomas Munro <[email protected]>; Alvaro Herrera <[email protected]>; [email protected] <[email protected]>; Heikki Linnakangas <[email protected]>
On Wed, May 8, 2024 at 03:44:12PM +0200, Peter Eisentraut wrote:
> 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.
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 <[email protected]> https://momjian.us
EDB https://enterprisedb.com
Only you can decide what is important to you.
^ permalink raw reply [nested|flat] 33+ messages in thread
* Re: AIX support
@ 2024-05-15 15:33 Sriram RK <[email protected]>
parent: Bruce Momjian <[email protected]>
0 siblings, 1 reply; 33+ messages in thread
From: Sriram RK @ 2024-05-15 15:33 UTC (permalink / raw)
To: Bruce Momjian <[email protected]>; Peter Eisentraut <[email protected]>; pgsql-hackers; Noah Misch <[email protected]>; +Cc: Michael Paquier <[email protected]>; Tom Lane <[email protected]>; Andres Freund <[email protected]>; Thomas Munro <[email protected]>; Alvaro Herrera <[email protected]>; [email protected] <[email protected]>; Heikki Linnakangas <[email protected]>
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.
>>/opt/IBM/xlC/16.1.0/bin/xlC align.c -o align.xl
>>./align.xl
al4096 4096 @ 0x20008000 (mod 0)
al4096_initialized 4096 @ 0x20004000 (mod 0)
al4096_const 4096 @ 0x2000b000 (mod 0)
al4096_const_initialized 4096 @ 0x10008000 (mod 0)
al4096_static 4096 @ 0x2000e000 (mod 0)
al4096_static_initialized 4096 @ 0x20001000 (mod 0)
al4096_static_const 4096 @ 0x20011000 (mod 0)
al4096_static_const_initialized 4096 @ 0x10001000 (mod 0)
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.
Regards,
Sriram.
^ permalink raw reply [nested|flat] 33+ messages in thread
* Re: AIX support
@ 2024-05-15 15:52 Noah Misch <[email protected]>
parent: Sriram RK <[email protected]>
0 siblings, 1 reply; 33+ messages in thread
From: Noah Misch @ 2024-05-15 15:52 UTC (permalink / raw)
To: Sriram RK <[email protected]>; +Cc: Bruce Momjian <[email protected]>; Peter Eisentraut <[email protected]>; pgsql-hackers; Michael Paquier <[email protected]>; Tom Lane <[email protected]>; Andres Freund <[email protected]>; Thomas Munro <[email protected]>; Alvaro Herrera <[email protected]>; [email protected] <[email protected]>; Heikki Linnakangas <[email protected]>
On Wed, May 15, 2024 at 03:33:25PM +0000, 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:
> https://www.ibm.com/support/pages/fix-list-xl-cc-aix.
>
> >>/opt/IBM/xlC/16.1.0/bin/xlC align.c -o align.xl
>
> >>./align.xl
> al4096 4096 @ 0x20008000 (mod 0)
> al4096_initialized 4096 @ 0x20004000 (mod 0)
> al4096_const 4096 @ 0x2000b000 (mod 0)
> al4096_const_initialized 4096 @ 0x10008000 (mod 0)
> al4096_static 4096 @ 0x2000e000 (mod 0)
> al4096_static_initialized 4096 @ 0x20001000 (mod 0)
> al4096_static_const 4096 @ 0x20011000 (mod 0)
> al4096_static_const_initialized 4096 @ 0x10001000 (mod 0)
That is good news. PGIOAlignedBlock is now in the IBM publication,
https://www.ibm.com/support/pages/apar/IJ51032
> 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 filled out the form at
https://buildfarm.postgresql.org/cgi-bin/register-form.pl? It can take a few
weeks, so I wouldn't worry yet.
^ permalink raw reply [nested|flat] 33+ messages in thread
* Re: AIX support
@ 2024-05-15 16:22 Sriram RK <[email protected]>
parent: Noah Misch <[email protected]>
0 siblings, 1 reply; 33+ messages in thread
From: Sriram RK @ 2024-05-15 16:22 UTC (permalink / raw)
To: Noah Misch <[email protected]>; +Cc: Bruce Momjian <[email protected]>; Peter Eisentraut <[email protected]>; pgsql-hackers; Michael Paquier <[email protected]>; Tom Lane <[email protected]>; Andres Freund <[email protected]>; Thomas Munro <[email protected]>; Alvaro Herrera <[email protected]>; [email protected] <[email protected]>; Heikki Linnakangas <[email protected]>
> > 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 filled out the form at
> https://buildfarm.postgresql.org/cgi-bin/register-form.pl? It can take a few
> weeks, so I wouldn't worry yet.
Thanks Noha, I had already submitted a form a week back, hope it might take another couple of weeks to get it approved.
^ permalink raw reply [nested|flat] 33+ messages in thread
* Re: AIX support
@ 2024-05-16 14:17 Sriram RK <[email protected]>
parent: Sriram RK <[email protected]>
0 siblings, 1 reply; 33+ messages in thread
From: Sriram RK @ 2024-05-16 14:17 UTC (permalink / raw)
To: Noah Misch <[email protected]>; pgsql-hackers; +Cc: Bruce Momjian <[email protected]>; Peter Eisentraut <[email protected]>; Michael Paquier <[email protected]>; Andres Freund <[email protected]>; Tom Lane <[email protected]>; Thomas Munro <[email protected]>; Alvaro Herrera <[email protected]>; [email protected] <[email protected]>; Heikki Linnakangas <[email protected]>
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
Compiler : gcc-12 & xlc(16.1.0.18)
Wed May 15 21:26:00 2024: buildfarm run for AIXnode01:HEAD starting
AIXnode01:HEAD [21:26:00] running configure ...
AIXnode01:HEAD [21:27:03] running build ...
AIXnode01:HEAD [21:27:27] running basic regression tests ...
AIXnode01:HEAD [21:34:41] running make contrib ...
AIXnode01:HEAD [21:34:43] running make testmodules ...
AIXnode01:HEAD [21:34:44] running install ...
AIXnode01:HEAD [21:34:58] running make contrib install ...
AIXnode01:HEAD [21:35:05] running testmodules install ...
AIXnode01:HEAD [21:35:08] checking pg_upgrade
AIXnode01:HEAD [21:35:08] checking test-decoding
AIXnode01:HEAD [21:35:29] running make check miscellaneous modules ...
AIXnode01:HEAD [21:36:16] setting up db cluster (C)...
AIXnode01:HEAD [21:36:19] starting db (C)...
AIXnode01:HEAD [21:36:19] running installcheck (C)...
AIXnode01:HEAD [21:46:27] restarting db (C)...
AIXnode01:HEAD [21:46:29] running make isolation check ...
AIXnode01:HEAD [21:49:57] restarting db (C)...
AIXnode01:HEAD [21:50:02] running make PL installcheck (C)...
AIXnode01:HEAD [21:50:09] restarting db (C)...
AIXnode01:HEAD [21:50:12] running make contrib installcheck (C)...
AIXnode01:HEAD [21:53:53] restarting db (C)...
AIXnode01:HEAD [21:53:56] running make test-modules installcheck (C)...
AIXnode01:HEAD [21:54:28] stopping db (C)...
AIXnode01:HEAD [21:54:29] running make ecpg check ...
AIXnode01:HEAD [21:54:45] OK
Branch: HEAD
All stages succeeded
The below changes are applied on this commit level
commit 54b69f1bd730a228a666441592a12d2a0cbe2a06 (HEAD -> pgAIX, origin/master, origin/HEAD, master)
On branch pgAIX
Changes to be committed:
(use "git restore --staged <file>..." to unstage)
new file: src/backend/port/aix/mkldexport.sh
new file: src/include/port/aix.h
new file: src/makefiles/Makefile.aix
new file: src/template/aix
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git restore <file>..." to discard changes in working directory)
modified: Makefile
modified: config/c-compiler.m4
modified: configure
modified: configure.ac
modified: doc/src/sgml/dfunc.sgml
modified: doc/src/sgml/installation.sgml
modified: doc/src/sgml/runtime.sgml
modified: meson.build
modified: src/Makefile.shlib
modified: src/backend/Makefile
modified: src/backend/meson.build
modified: src/backend/storage/buffer/bufmgr.c
modified: src/backend/utils/error/elog.c
modified: src/backend/utils/misc/ps_status.c
modified: src/bin/pg_basebackup/t/010_pg_basebackup.pl
modified: src/bin/pg_verifybackup/t/008_untar.pl
modified: src/bin/pg_verifybackup/t/010_client_untar.pl
modified: src/include/c.h
modified: src/include/port/atomics.h
modified: src/include/storage/s_lock.h
modified: src/interfaces/libpq/Makefile
modified: src/interfaces/libpq/meson.build
modified: src/port/README
modified: src/port/strerror.c
modified: src/test/regress/Makefile
modified: src/test/regress/expected/sanity_check.out
modified: src/test/regress/expected/test_setup.out
modified: src/test/regress/regress.c
modified: src/test/regress/sql/sanity_check.sql
modified: src/test/regress/sql/test_setup.sql
modified: src/tools/gen_export.pl
modified: src/tools/pginclude/headerscheck
Can you please let us know, the process to post the changes for review?
Regards,
Sriram.
^ permalink raw reply [nested|flat] 33+ messages in thread
* Re: AIX support
@ 2024-05-16 14:30 Alvaro Herrera <[email protected]>
parent: Sriram RK <[email protected]>
0 siblings, 1 reply; 33+ messages in thread
From: Alvaro Herrera @ 2024-05-16 14:30 UTC (permalink / raw)
To: Sriram RK <[email protected]>; +Cc: Noah Misch <[email protected]>; pgsql-hackers; Bruce Momjian <[email protected]>; Peter Eisentraut <[email protected]>; Michael Paquier <[email protected]>; Andres Freund <[email protected]>; Tom Lane <[email protected]>; Thomas Munro <[email protected]>; [email protected] <[email protected]>; Heikki Linnakangas <[email protected]>
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.
> Can you please let us know, the process to post the changes for review?
Here's some very good advice
https://postgr.es/m/[email protected]
Regards
--
Álvaro Herrera
^ permalink raw reply [nested|flat] 33+ messages in thread
* Re: AIX support
@ 2024-05-22 16:15 Sriram RK <[email protected]>
parent: Alvaro Herrera <[email protected]>
0 siblings, 0 replies; 33+ messages in thread
From: Sriram RK @ 2024-05-22 16:15 UTC (permalink / raw)
To: Alvaro Herrera <[email protected]>; pgsql-hackers; Noah Misch <[email protected]>; Heikki Linnakangas <[email protected]>; +Cc: Bruce Momjian <[email protected]>; Peter Eisentraut <[email protected]>; Michael Paquier <[email protected]>; Andres Freund <[email protected]>; Tom Lane <[email protected]>; Thomas Munro <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]>
Thanks Alvaro, for the info…
Hi Team,
We referred to the below links to build this patch …
https://wiki.postgresql.org/wiki/Submitting_a_Patch
https://peter.eisentraut.org/blog/2023/05/09/how-to-submit-a-patch-by-email-2023-edition
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.
src/backend/storage/buffer/bufmgr.c
"bufmgr.c", line 811.39: 1506-780 (S) Reference to "RelationGetSmgr" with internal linkage is not allowed within inline definition of "ReadBufferExtended".
"bufmgr.c", line 811.15: 1506-780 (S) Reference to "ReadBuffer_common" with internal linkage is not allowed within inline definition of "ReadBufferExtended".
gmake[4]: *** [<builtin>: bufmgr.o] Error 1
Please let us know your feedback.
Thanks,
Sriram.
Attachments:
[application/octet-stream] 0001-AIX-support-revert-the-changes-from-0b16bb8776bb8.patch (61.1K, 3-0001-AIX-support-revert-the-changes-from-0b16bb8776bb8.patch)
download | inline diff:
From 15d0cf54ee49a88c566cb439396b870d5e6c392c Mon Sep 17 00:00:00 2001
From: Sriram RK <[email protected]>
Date: Mon, 20 May 2024 01:38:59 -0500
Subject: [PATCH] AIX support, revert the changes from 0b16bb8776bb8.
---
Makefile | 2 -
config/c-compiler.m4 | 2 +-
configure | 329 ++++++++++++++++--
configure.ac | 55 +--
doc/src/sgml/dfunc.sgml | 19 +
doc/src/sgml/installation.sgml | 119 ++++++-
doc/src/sgml/runtime.sgml | 23 ++
meson.build | 57 +--
src/Makefile.shlib | 29 ++
src/backend/Makefile | 20 ++
src/backend/meson.build | 15 +
src/backend/port/aix/mkldexport.sh | 61 ++++
src/backend/storage/buffer/bufmgr.c | 2 +-
src/backend/utils/error/elog.c | 2 +
src/backend/utils/misc/ps_status.c | 4 +-
src/bin/pg_basebackup/t/010_pg_basebackup.pl | 3 +-
src/bin/pg_verifybackup/t/008_untar.pl | 3 +-
src/bin/pg_verifybackup/t/010_client_untar.pl | 3 +-
src/include/c.h | 18 +-
src/include/port/aix.h | 14 +
src/include/port/atomics.h | 6 +-
src/include/storage/s_lock.h | 31 +-
src/interfaces/libpq/Makefile | 2 +-
src/interfaces/libpq/meson.build | 5 +-
src/makefiles/Makefile.aix | 39 +++
src/port/README | 2 +-
src/port/strerror.c | 2 +
src/template/aix | 25 ++
src/test/regress/Makefile | 5 +
src/test/regress/expected/sanity_check.out | 29 ++
src/test/regress/expected/test_setup.out | 4 +
src/test/regress/regress.c | 40 +++
src/test/regress/sql/sanity_check.sql | 26 ++
src/test/regress/sql/test_setup.sql | 5 +
src/tools/gen_export.pl | 11 +-
src/tools/pginclude/headerscheck | 1 +
36 files changed, 908 insertions(+), 105 deletions(-)
create mode 100755 src/backend/port/aix/mkldexport.sh
create mode 100644 src/include/port/aix.h
create mode 100644 src/makefiles/Makefile.aix
create mode 100644 src/template/aix
diff --git a/Makefile b/Makefile
index 8a2ec9396b..9bc1a4ec17 100644
--- a/Makefile
+++ b/Makefile
@@ -13,8 +13,6 @@
# AIX make defaults to building *every* target of the first rule. Start with
# a single-target, empty rule to make the other targets non-default.
-# (We don't support AIX anymore, but if someone tries to build on AIX anyway,
-# at least they'll get the instructions to run 'configure' first.)
all:
all check install installdirs installcheck installcheck-parallel uninstall clean distclean maintainer-clean dist distcheck world check-world install-world installcheck-world:
diff --git a/config/c-compiler.m4 b/config/c-compiler.m4
index 10f8c7bd0a..ad99b91032 100644
--- a/config/c-compiler.m4
+++ b/config/c-compiler.m4
@@ -137,7 +137,7 @@ if test x"$pgac_cv__128bit_int" = xyes ; then
AC_CACHE_CHECK([for __int128 alignment bug], [pgac_cv__128bit_int_bug],
[AC_RUN_IFELSE([AC_LANG_PROGRAM([
/* This must match the corresponding code in c.h: */
-#if defined(__GNUC__) || defined(__SUNPRO_C)
+#if defined(__GNUC__) || defined(__SUNPRO_C) || defined(__IBMC__)
#define pg_attribute_aligned(a) __attribute__((aligned(a)))
#elif defined(_MSC_VER)
#define pg_attribute_aligned(a) __declspec(align(a))
diff --git a/configure b/configure
index 89644f2249..8ca7ec5cfe 100755
--- a/configure
+++ b/configure
@@ -2988,6 +2988,7 @@ else
# --with-template not given
case $host_os in
+ aix*) template=aix ;;
cygwin*|msys*) template=cygwin ;;
darwin*) template=darwin ;;
dragonfly*) template=netbsd ;;
@@ -3894,8 +3895,10 @@ _ACEOF
# If you don't specify a list of compilers to test, the AC_PROG_CC and
# AC_PROG_CXX macros test for a long list of unsupported compilers.
-pgac_cc_list="gcc cc"
-pgac_cxx_list="g++ c++"
+case $template in
+ aix) pgac_cc_list="gcc xlc"; pgac_cxx_list="g++ xlC";;
+ *) pgac_cc_list="gcc cc"; pgac_cxx_list="g++ c++";;
+esac
ac_ext=c
ac_cpp='$CPP $CPPFLAGS'
@@ -6849,6 +6852,190 @@ if test x"$pgac_cv_prog_CXX_cxxflags__fno_strict_aliasing" = x"yes"; then
fi
+elif test "$PORTNAME" = "aix"; then
+ # AIX's xlc has to have strict aliasing turned off too
+
+{ $as_echo "$as_me:${as_lineno-$LINENO}: checking whether ${CC} supports -qnoansialias, for CFLAGS" >&5
+$as_echo_n "checking whether ${CC} supports -qnoansialias, for CFLAGS... " >&6; }
+if ${pgac_cv_prog_CC_cflags__qnoansialias+:} false; then :
+ $as_echo_n "(cached) " >&6
+else
+ pgac_save_CFLAGS=$CFLAGS
+pgac_save_CC=$CC
+CC=${CC}
+CFLAGS="${CFLAGS} -qnoansialias"
+ac_save_c_werror_flag=$ac_c_werror_flag
+ac_c_werror_flag=yes
+cat confdefs.h - <<_ACEOF >conftest.$ac_ext
+/* end confdefs.h. */
+
+int
+main ()
+{
+
+ ;
+ return 0;
+}
+_ACEOF
+if ac_fn_c_try_compile "$LINENO"; then :
+ pgac_cv_prog_CC_cflags__qnoansialias=yes
+else
+ pgac_cv_prog_CC_cflags__qnoansialias=no
+fi
+rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
+ac_c_werror_flag=$ac_save_c_werror_flag
+CFLAGS="$pgac_save_CFLAGS"
+CC="$pgac_save_CC"
+fi
+{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $pgac_cv_prog_CC_cflags__qnoansialias" >&5
+$as_echo "$pgac_cv_prog_CC_cflags__qnoansialias" >&6; }
+if test x"$pgac_cv_prog_CC_cflags__qnoansialias" = x"yes"; then
+ CFLAGS="${CFLAGS} -qnoansialias"
+fi
+
+
+ { $as_echo "$as_me:${as_lineno-$LINENO}: checking whether ${CXX} supports -qnoansialias, for CXXFLAGS" >&5
+$as_echo_n "checking whether ${CXX} supports -qnoansialias, for CXXFLAGS... " >&6; }
+if ${pgac_cv_prog_CXX_cxxflags__qnoansialias+:} false; then :
+ $as_echo_n "(cached) " >&6
+else
+ pgac_save_CXXFLAGS=$CXXFLAGS
+pgac_save_CXX=$CXX
+CXX=${CXX}
+CXXFLAGS="${CXXFLAGS} -qnoansialias"
+ac_save_cxx_werror_flag=$ac_cxx_werror_flag
+ac_cxx_werror_flag=yes
+ac_ext=cpp
+ac_cpp='$CXXCPP $CPPFLAGS'
+ac_compile='$CXX -c $CXXFLAGS $CPPFLAGS conftest.$ac_ext >&5'
+ac_link='$CXX -o conftest$ac_exeext $CXXFLAGS $CPPFLAGS $LDFLAGS conftest.$ac_ext $LIBS >&5'
+ac_compiler_gnu=$ac_cv_cxx_compiler_gnu
+
+cat confdefs.h - <<_ACEOF >conftest.$ac_ext
+/* end confdefs.h. */
+
+int
+main ()
+{
+
+ ;
+ return 0;
+}
+_ACEOF
+if ac_fn_cxx_try_compile "$LINENO"; then :
+ pgac_cv_prog_CXX_cxxflags__qnoansialias=yes
+else
+ pgac_cv_prog_CXX_cxxflags__qnoansialias=no
+fi
+rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
+ac_ext=c
+ac_cpp='$CPP $CPPFLAGS'
+ac_compile='$CC -c $CFLAGS $CPPFLAGS conftest.$ac_ext >&5'
+ac_link='$CC -o conftest$ac_exeext $CFLAGS $CPPFLAGS $LDFLAGS conftest.$ac_ext $LIBS >&5'
+ac_compiler_gnu=$ac_cv_c_compiler_gnu
+
+ac_cxx_werror_flag=$ac_save_cxx_werror_flag
+CXXFLAGS="$pgac_save_CXXFLAGS"
+CXX="$pgac_save_CXX"
+fi
+{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $pgac_cv_prog_CXX_cxxflags__qnoansialias" >&5
+$as_echo "$pgac_cv_prog_CXX_cxxflags__qnoansialias" >&6; }
+if test x"$pgac_cv_prog_CXX_cxxflags__qnoansialias" = x"yes"; then
+ CXXFLAGS="${CXXFLAGS} -qnoansialias"
+fi
+
+
+
+{ $as_echo "$as_me:${as_lineno-$LINENO}: checking whether ${CC} supports -qlonglong, for CFLAGS" >&5
+$as_echo_n "checking whether ${CC} supports -qlonglong, for CFLAGS... " >&6; }
+if ${pgac_cv_prog_CC_cflags__qlonglong+:} false; then :
+ $as_echo_n "(cached) " >&6
+else
+ pgac_save_CFLAGS=$CFLAGS
+pgac_save_CC=$CC
+CC=${CC}
+CFLAGS="${CFLAGS} -qlonglong"
+ac_save_c_werror_flag=$ac_c_werror_flag
+ac_c_werror_flag=yes
+cat confdefs.h - <<_ACEOF >conftest.$ac_ext
+/* end confdefs.h. */
+
+int
+main ()
+{
+
+ ;
+ return 0;
+}
+_ACEOF
+if ac_fn_c_try_compile "$LINENO"; then :
+ pgac_cv_prog_CC_cflags__qlonglong=yes
+else
+ pgac_cv_prog_CC_cflags__qlonglong=no
+fi
+rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
+ac_c_werror_flag=$ac_save_c_werror_flag
+CFLAGS="$pgac_save_CFLAGS"
+CC="$pgac_save_CC"
+fi
+{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $pgac_cv_prog_CC_cflags__qlonglong" >&5
+$as_echo "$pgac_cv_prog_CC_cflags__qlonglong" >&6; }
+if test x"$pgac_cv_prog_CC_cflags__qlonglong" = x"yes"; then
+ CFLAGS="${CFLAGS} -qlonglong"
+fi
+
+
+ { $as_echo "$as_me:${as_lineno-$LINENO}: checking whether ${CXX} supports -qlonglong, for CXXFLAGS" >&5
+$as_echo_n "checking whether ${CXX} supports -qlonglong, for CXXFLAGS... " >&6; }
+if ${pgac_cv_prog_CXX_cxxflags__qlonglong+:} false; then :
+ $as_echo_n "(cached) " >&6
+else
+ pgac_save_CXXFLAGS=$CXXFLAGS
+pgac_save_CXX=$CXX
+CXX=${CXX}
+CXXFLAGS="${CXXFLAGS} -qlonglong"
+ac_save_cxx_werror_flag=$ac_cxx_werror_flag
+ac_cxx_werror_flag=yes
+ac_ext=cpp
+ac_cpp='$CXXCPP $CPPFLAGS'
+ac_compile='$CXX -c $CXXFLAGS $CPPFLAGS conftest.$ac_ext >&5'
+ac_link='$CXX -o conftest$ac_exeext $CXXFLAGS $CPPFLAGS $LDFLAGS conftest.$ac_ext $LIBS >&5'
+ac_compiler_gnu=$ac_cv_cxx_compiler_gnu
+
+cat confdefs.h - <<_ACEOF >conftest.$ac_ext
+/* end confdefs.h. */
+
+int
+main ()
+{
+
+ ;
+ return 0;
+}
+_ACEOF
+if ac_fn_cxx_try_compile "$LINENO"; then :
+ pgac_cv_prog_CXX_cxxflags__qlonglong=yes
+else
+ pgac_cv_prog_CXX_cxxflags__qlonglong=no
+fi
+rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
+ac_ext=c
+ac_cpp='$CPP $CPPFLAGS'
+ac_compile='$CC -c $CFLAGS $CPPFLAGS conftest.$ac_ext >&5'
+ac_link='$CC -o conftest$ac_exeext $CFLAGS $CPPFLAGS $LDFLAGS conftest.$ac_ext $LIBS >&5'
+ac_compiler_gnu=$ac_cv_c_compiler_gnu
+
+ac_cxx_werror_flag=$ac_save_cxx_werror_flag
+CXXFLAGS="$pgac_save_CXXFLAGS"
+CXX="$pgac_save_CXX"
+fi
+{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $pgac_cv_prog_CXX_cxxflags__qlonglong" >&5
+$as_echo "$pgac_cv_prog_CXX_cxxflags__qlonglong" >&6; }
+if test x"$pgac_cv_prog_CXX_cxxflags__qlonglong" = x"yes"; then
+ CXXFLAGS="${CXXFLAGS} -qlonglong"
+fi
+
+
fi
# If the compiler knows how to hide symbols, add the switch needed for that to
@@ -7003,6 +7190,103 @@ if test x"$pgac_cv_prog_CXX_cxxflags__fvisibility_inlines_hidden" = x"yes"; then
fi
have_visibility_attribute=$pgac_cv_prog_CC_cflags__fvisibility_hidden
+elif test "$PORTNAME" = "aix"; then
+ # Note that xlc accepts -fvisibility=hidden as a file.
+ { $as_echo "$as_me:${as_lineno-$LINENO}: checking whether ${CC} supports -qvisibility=hidden, for CFLAGS_SL_MODULE" >&5
+$as_echo_n "checking whether ${CC} supports -qvisibility=hidden, for CFLAGS_SL_MODULE... " >&6; }
+if ${pgac_cv_prog_CC_cflags__qvisibility_hidden+:} false; then :
+ $as_echo_n "(cached) " >&6
+else
+ pgac_save_CFLAGS=$CFLAGS
+pgac_save_CC=$CC
+CC=${CC}
+CFLAGS="${CFLAGS_SL_MODULE} -qvisibility=hidden"
+ac_save_c_werror_flag=$ac_c_werror_flag
+ac_c_werror_flag=yes
+cat confdefs.h - <<_ACEOF >conftest.$ac_ext
+/* end confdefs.h. */
+
+int
+main ()
+{
+
+ ;
+ return 0;
+}
+_ACEOF
+if ac_fn_c_try_compile "$LINENO"; then :
+ pgac_cv_prog_CC_cflags__qvisibility_hidden=yes
+else
+ pgac_cv_prog_CC_cflags__qvisibility_hidden=no
+fi
+rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
+ac_c_werror_flag=$ac_save_c_werror_flag
+CFLAGS="$pgac_save_CFLAGS"
+CC="$pgac_save_CC"
+fi
+{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $pgac_cv_prog_CC_cflags__qvisibility_hidden" >&5
+$as_echo "$pgac_cv_prog_CC_cflags__qvisibility_hidden" >&6; }
+if test x"$pgac_cv_prog_CC_cflags__qvisibility_hidden" = x"yes"; then
+ CFLAGS_SL_MODULE="${CFLAGS_SL_MODULE} -qvisibility=hidden"
+fi
+
+
+ { $as_echo "$as_me:${as_lineno-$LINENO}: checking whether ${CXX} supports -qvisibility=hidden, for CXXFLAGS_SL_MODULE" >&5
+$as_echo_n "checking whether ${CXX} supports -qvisibility=hidden, for CXXFLAGS_SL_MODULE... " >&6; }
+if ${pgac_cv_prog_CXX_cxxflags__qvisibility_hidden+:} false; then :
+ $as_echo_n "(cached) " >&6
+else
+ pgac_save_CXXFLAGS=$CXXFLAGS
+pgac_save_CXX=$CXX
+CXX=${CXX}
+CXXFLAGS="${CXXFLAGS_SL_MODULE} -qvisibility=hidden"
+ac_save_cxx_werror_flag=$ac_cxx_werror_flag
+ac_cxx_werror_flag=yes
+ac_ext=cpp
+ac_cpp='$CXXCPP $CPPFLAGS'
+ac_compile='$CXX -c $CXXFLAGS $CPPFLAGS conftest.$ac_ext >&5'
+ac_link='$CXX -o conftest$ac_exeext $CXXFLAGS $CPPFLAGS $LDFLAGS conftest.$ac_ext $LIBS >&5'
+ac_compiler_gnu=$ac_cv_cxx_compiler_gnu
+
+cat confdefs.h - <<_ACEOF >conftest.$ac_ext
+/* end confdefs.h. */
+
+int
+main ()
+{
+
+ ;
+ return 0;
+}
+_ACEOF
+if ac_fn_cxx_try_compile "$LINENO"; then :
+ pgac_cv_prog_CXX_cxxflags__qvisibility_hidden=yes
+else
+ pgac_cv_prog_CXX_cxxflags__qvisibility_hidden=no
+fi
+rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
+ac_ext=c
+ac_cpp='$CPP $CPPFLAGS'
+ac_compile='$CC -c $CFLAGS $CPPFLAGS conftest.$ac_ext >&5'
+ac_link='$CC -o conftest$ac_exeext $CFLAGS $CPPFLAGS $LDFLAGS conftest.$ac_ext $LIBS >&5'
+ac_compiler_gnu=$ac_cv_c_compiler_gnu
+
+ac_cxx_werror_flag=$ac_save_cxx_werror_flag
+CXXFLAGS="$pgac_save_CXXFLAGS"
+CXX="$pgac_save_CXX"
+fi
+{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $pgac_cv_prog_CXX_cxxflags__qvisibility_hidden" >&5
+$as_echo "$pgac_cv_prog_CXX_cxxflags__qvisibility_hidden" >&6; }
+if test x"$pgac_cv_prog_CXX_cxxflags__qvisibility_hidden" = x"yes"; then
+ CXXFLAGS_SL_MODULE="${CXXFLAGS_SL_MODULE} -qvisibility=hidden"
+fi
+
+ have_visibility_attribute=$pgac_cv_prog_CC_cflags__qvisibility_hidden
+ # Old xlc versions (<13.1) don't have support for -qvisibility. Use expfull to force
+ # all extension module symbols to be exported.
+ if test "$pgac_cv_prog_CC_cflags__qvisibility_hidden" != "yes"; then
+ CFLAGS_SL_MODULE="$CFLAGS_SL_MODULE -Wl,-b,expfull"
+ fi
fi
if test "$have_visibility_attribute" = "yes"; then
@@ -12860,7 +13144,8 @@ fi
fi
-# Note: We can test for libldap_r only after we know PTHREAD_LIBS
+# Note: We can test for libldap_r only after we know PTHREAD_LIBS;
+# also, on AIX, we may need to have openssl in LIBS for this step.
if test "$with_ldap" = yes ; then
_LIBS="$LIBS"
if test "$PORTNAME" != "win32"; then
@@ -14718,6 +15003,10 @@ fi
# spelling it understands, because it conflicts with
# __declspec(restrict). Therefore we define pg_restrict to the
# appropriate definition, which presumably won't conflict.
+#
+# Allow platforms with buggy compilers to force restrict to not be
+# used by setting $FORCE_DISABLE_RESTRICT=yes in the relevant
+# template.
{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for C/C++ restrict keyword" >&5
$as_echo_n "checking for C/C++ restrict keyword... " >&6; }
if ${ac_cv_c_restrict+:} false; then :
@@ -14764,7 +15053,7 @@ _ACEOF
;;
esac
-if test "$ac_cv_c_restrict" = "no"; then
+if test "$ac_cv_c_restrict" = "no" -o "x$FORCE_DISABLE_RESTRICT" = "xyes"; then
pg_restrict=""
else
pg_restrict="$ac_cv_c_restrict"
@@ -16951,28 +17240,18 @@ _ACEOF
# Compute maximum alignment of any basic type.
-#
-# We require 'double' to have the strictest alignment among the basic types,
-# because otherwise the C ABI might impose 8-byte alignment on some of the
-# other C types that correspond to TYPALIGN_DOUBLE SQL types. That could
-# cause a mismatch between the tuple layout and the C struct layout of a
-# catalog tuple. We used to carefully order catalog columns such that any
-# fixed-width, attalign=4 columns were at offsets divisible by 8 regardless
-# of MAXIMUM_ALIGNOF to avoid that, but we no longer support any platforms
-# where TYPALIGN_DOUBLE != MAXIMUM_ALIGNOF.
-#
-# We assume without checking that long's alignment is at least as strong as
-# char, short, or int. Note that we intentionally do not consider any types
-# wider than 64 bits, as allowing MAXIMUM_ALIGNOF to exceed 8 would be too
-# much of a penalty for disk and memory space.
-
-MAX_ALIGNOF=$ac_cv_alignof_double
+# We assume long's alignment is at least as strong as char, short, or int;
+# but we must check long long (if it is being used for int64) and double.
+# Note that we intentionally do not consider any types wider than 64 bits,
+# as allowing MAXIMUM_ALIGNOF to exceed 8 would be too much of a penalty
+# for disk and memory space.
-if test $ac_cv_alignof_long -gt $MAX_ALIGNOF ; then
- as_fn_error $? "alignment of 'long' is greater than the alignment of 'double'" "$LINENO" 5
+MAX_ALIGNOF=$ac_cv_alignof_long
+if test $MAX_ALIGNOF -lt $ac_cv_alignof_double ; then
+ MAX_ALIGNOF=$ac_cv_alignof_double
fi
-if test x"$HAVE_LONG_LONG_INT_64" = xyes && test $ac_cv_alignof_long_long_int -gt $MAX_ALIGNOF ; then
- as_fn_error $? "alignment of 'long long int' is greater than the alignment of 'double'" "$LINENO" 5
+if test x"$HAVE_LONG_LONG_INT_64" = xyes && test $MAX_ALIGNOF -lt $ac_cv_alignof_long_long_int ; then
+ MAX_ALIGNOF="$ac_cv_alignof_long_long_int"
fi
cat >>confdefs.h <<_ACEOF
@@ -17090,7 +17369,7 @@ else
/* end confdefs.h. */
/* This must match the corresponding code in c.h: */
-#if defined(__GNUC__) || defined(__SUNPRO_C)
+#if defined(__GNUC__) || defined(__SUNPRO_C) || defined(__IBMC__)
#define pg_attribute_aligned(a) __attribute__((aligned(a)))
#elif defined(_MSC_VER)
#define pg_attribute_aligned(a) __declspec(align(a))
diff --git a/configure.ac b/configure.ac
index c7322e292c..b2e19cf822 100644
--- a/configure.ac
+++ b/configure.ac
@@ -62,6 +62,7 @@ PGAC_ARG_REQ(with, template, [NAME], [override operating system template],
# --with-template not given
case $host_os in
+ aix*) template=aix ;;
cygwin*|msys*) template=cygwin ;;
darwin*) template=darwin ;;
dragonfly*) template=netbsd ;;
@@ -368,10 +369,10 @@ AC_DEFINE_UNQUOTED([XLOG_BLCKSZ], ${XLOG_BLCKSZ}, [
# C compiler
#
-# If you don't specify a list of compilers to test, the AC_PROG_CC and
-# AC_PROG_CXX macros test for a long list of unsupported compilers.
-pgac_cc_list="gcc cc"
-pgac_cxx_list="g++ c++"
+case $template in
+ aix) pgac_cc_list="gcc xlc"; pgac_cxx_list="g++ xlC";;
+ *) pgac_cc_list="gcc cc"; pgac_cxx_list="g++ c++";;
+esac
AC_PROG_CC([$pgac_cc_list])
AC_PROG_CC_C99()
@@ -588,6 +589,12 @@ elif test "$ICC" = yes; then
# Make sure strict aliasing is off (though this is said to be the default)
PGAC_PROG_CC_CFLAGS_OPT([-fno-strict-aliasing])
PGAC_PROG_CXX_CFLAGS_OPT([-fno-strict-aliasing])
+elif test "$PORTNAME" = "aix"; then
+ # AIX's xlc has to have strict aliasing turned off too
+ PGAC_PROG_CC_CFLAGS_OPT([-qnoansialias])
+ PGAC_PROG_CXX_CFLAGS_OPT([-qnoansialias])
+ PGAC_PROG_CC_CFLAGS_OPT([-qlonglong])
+ PGAC_PROG_CXX_CFLAGS_OPT([-qlonglong])
fi
# If the compiler knows how to hide symbols, add the switch needed for that to
@@ -606,6 +613,16 @@ if test "$GCC" = yes -o "$SUN_STUDIO_CC" = yes ; then
PGAC_PROG_VARCXX_VARFLAGS_OPT(CXX, CXXFLAGS_SL_MODULE, [-fvisibility=hidden])
PGAC_PROG_VARCXX_VARFLAGS_OPT(CXX, CXXFLAGS_SL_MODULE, [-fvisibility-inlines-hidden])
have_visibility_attribute=$pgac_cv_prog_CC_cflags__fvisibility_hidden
+elif test "$PORTNAME" = "aix"; then
+ # Note that xlc accepts -fvisibility=hidden as a file.
+ PGAC_PROG_CC_VAR_OPT(CFLAGS_SL_MODULE, [-qvisibility=hidden])
+ PGAC_PROG_VARCXX_VARFLAGS_OPT(CXX, CXXFLAGS_SL_MODULE, [-qvisibility=hidden])
+ have_visibility_attribute=$pgac_cv_prog_CC_cflags__qvisibility_hidden
+ # Old xlc versions (<13.1) don't have support for -qvisibility. Use expfull to force
+ # all extension module symbols to be exported.
+ if test "$pgac_cv_prog_CC_cflags__qvisibility_hidden" != "yes"; then
+ CFLAGS_SL_MODULE="$CFLAGS_SL_MODULE -Wl,-b,expfull"
+ fi
fi
if test "$have_visibility_attribute" = "yes"; then
@@ -1385,7 +1402,8 @@ if test "$with_zstd" = yes ; then
AC_CHECK_LIB(zstd, ZSTD_compress, [], [AC_MSG_ERROR([library 'zstd' is required for ZSTD support])])
fi
-# Note: We can test for libldap_r only after we know PTHREAD_LIBS
+# Note: We can test for libldap_r only after we know PTHREAD_LIBS;
+# also, on AIX, we may need to have openssl in LIBS for this step.
if test "$with_ldap" = yes ; then
_LIBS="$LIBS"
if test "$PORTNAME" != "win32"; then
@@ -1643,8 +1661,12 @@ PGAC_TYPE_LOCALE_T
# spelling it understands, because it conflicts with
# __declspec(restrict). Therefore we define pg_restrict to the
# appropriate definition, which presumably won't conflict.
+#
+# Allow platforms with buggy compilers to force restrict to not be
+# used by setting $FORCE_DISABLE_RESTRICT=yes in the relevant
+# template.
AC_C_RESTRICT
-if test "$ac_cv_c_restrict" = "no"; then
+if test "$ac_cv_c_restrict" = "no" -o "x$FORCE_DISABLE_RESTRICT" = "xyes"; then
pg_restrict=""
else
pg_restrict="$ac_cv_c_restrict"
@@ -1996,22 +2018,11 @@ fi
AC_CHECK_ALIGNOF(double)
# Compute maximum alignment of any basic type.
-#
-# We require 'double' to have the strictest alignment among the basic types,
-# because otherwise the C ABI might impose 8-byte alignment on some of the
-# other C types that correspond to TYPALIGN_DOUBLE SQL types. That could
-# cause a mismatch between the tuple layout and the C struct layout of a
-# catalog tuple. We used to carefully order catalog columns such that any
-# fixed-width, attalign=4 columns were at offsets divisible by 8 regardless
-# of MAXIMUM_ALIGNOF to avoid that, but we no longer support any platforms
-# where TYPALIGN_DOUBLE != MAXIMUM_ALIGNOF.
-#
-# We assume without checking that long's alignment is at least as strong as
-# char, short, or int. Note that we intentionally do not consider any types
-# wider than 64 bits, as allowing MAXIMUM_ALIGNOF to exceed 8 would be too
-# much of a penalty for disk and memory space.
-
-MAX_ALIGNOF=$ac_cv_alignof_double
+# We assume long's alignment is at least as strong as char, short, or int;
+# but we must check long long (if it is being used for int64) and double.
+# Note that we intentionally do not consider any types wider than 64 bits,
+# as allowing MAXIMUM_ALIGNOF to exceed 8 would be too much of a penalty
+# for disk and memory space.
if test $ac_cv_alignof_long -gt $MAX_ALIGNOF ; then
AC_MSG_ERROR([alignment of 'long' is greater than the alignment of 'double'])
diff --git a/doc/src/sgml/dfunc.sgml b/doc/src/sgml/dfunc.sgml
index b94aefcd0c..554f9fac4c 100644
--- a/doc/src/sgml/dfunc.sgml
+++ b/doc/src/sgml/dfunc.sgml
@@ -202,4 +202,23 @@ gcc -G -o foo.so foo.o
server expects to find the shared library files.
</para>
+<!--
+Under AIX, object files are compiled normally but building the shared
+library requires a couple of steps. First, create the object file:
+.nf
+cc <other flags> -c foo.c
+.fi
+You must then create a symbol \*(lqexports\*(rq file for the object
+file:
+.nf
+mkldexport foo.o `pwd` > foo.exp
+.fi
+Finally, you can create the shared library:
+.nf
+ld <other flags> -H512 -T512 -o foo.so -e _nostart \e
+ -bI:.../lib/postgres.exp -bE:foo.exp foo.o \e
+ -lm -lc 2>/dev/null
+.fi
+ -->
+
</sect2>
diff --git a/doc/src/sgml/installation.sgml b/doc/src/sgml/installation.sgml
index 1b32d5ca62..6b27a1250b 100644
--- a/doc/src/sgml/installation.sgml
+++ b/doc/src/sgml/installation.sgml
@@ -3401,7 +3401,7 @@ export MANPATH
<para>
<productname>PostgreSQL</productname> can be expected to work on current
versions of these operating systems: Linux, Windows,
- FreeBSD, OpenBSD, NetBSD, DragonFlyBSD, macOS, Solaris, and illumos.
+ FreeBSD, OpenBSD, NetBSD, DragonFlyBSD, macOS, AIX, Solaris, and illumos.
Other Unix-like systems may also work but are not currently
being tested. In most cases, all CPU architectures supported by
a given operating system will work. Look in
@@ -3445,6 +3445,123 @@ export MANPATH
installation issues.
</para>
+ <sect2 id="installation-notes-aix">
+ <title>AIX</title>
+
+ <indexterm zone="installation-notes-aix">
+ <primary>AIX</primary>
+ <secondary>installation on</secondary>
+ </indexterm>
+
+ <para>
+ You can use GCC or the native IBM compiler <command>xlc</command>
+ to build <productname>PostgreSQL</productname>
+ on <productname>AIX</productname>.
+ </para>
+
+ <para>
+ <productname>AIX</productname> versions before 7.1 are no longer
+ tested nor supported by the <productname>PostgreSQL</productname>
+ community.
+ </para>
+
+ <sect3 id="installation-notes-aix-mem-management">
+ <title>Memory Management</title>
+ <!-- https://archives.postgresql.org/message-id/[email protected] -->
+
+ <para>
+ AIX can be somewhat peculiar with regards to the way it does
+ memory management. You can have a server with many multiples of
+ gigabytes of RAM free, but still get out of memory or address
+ space errors when running applications. One example
+ is loading of extensions failing with unusual errors.
+ For example, running as the owner of the PostgreSQL installation:
+<screen>
+=# CREATE EXTENSION plperl;
+ERROR: could not load library "/opt/dbs/pgsql/lib/plperl.so": A memory address is not in the address space for the process.
+</screen>
+ Running as a non-owner in the group possessing the PostgreSQL
+ installation:
+<screen>
+=# CREATE EXTENSION plperl;
+ERROR: could not load library "/opt/dbs/pgsql/lib/plperl.so": Bad address
+</screen>
+ Another example is out of memory errors in the PostgreSQL server
+ logs, with every memory allocation near or greater than 256 MB
+ failing.
+ </para>
+
+ <para>
+ The overall cause of all these problems is the default bittedness
+ and memory model used by the server process. By default, all
+ binaries built on AIX are 32-bit. This does not depend upon
+ hardware type or kernel in use. These 32-bit processes are
+ limited to 4 GB of memory laid out in 256 MB segments using one
+ of a few models. The default allows for less than 256 MB in the
+ heap as it shares a single segment with the stack.
+ </para>
+
+ <para>
+ In the case of the <literal>plperl</literal> example, above,
+ check your umask and the permissions of the binaries in your
+ PostgreSQL installation. The binaries involved in that example
+ were 32-bit and installed as mode 750 instead of 755. Due to the
+ permissions being set in this fashion, only the owner or a member
+ of the possessing group can load the library. Since it isn't
+ world-readable, the loader places the object into the process'
+ heap instead of the shared library segments where it would
+ otherwise be placed.
+ </para>
+
+ <para>
+ The <quote>ideal</quote> solution for this is to use a 64-bit
+ build of PostgreSQL, but that is not always practical, because
+ systems with 32-bit processors can build, but not run, 64-bit
+ binaries.
+ </para>
+
+ <para>
+ If a 32-bit binary is desired, set <symbol>LDR_CNTRL</symbol> to
+ <literal>MAXDATA=0x<replaceable>n</replaceable>0000000</literal>,
+ where 1 <= n <= 8, before starting the PostgreSQL server,
+ and try different values and <filename>postgresql.conf</filename>
+ settings to find a configuration that works satisfactorily. This
+ use of <symbol>LDR_CNTRL</symbol> tells AIX that you want the
+ server to have <symbol>MAXDATA</symbol> bytes set aside for the
+ heap, allocated in 256 MB segments. When you find a workable
+ configuration,
+ <command>ldedit</command> can be used to modify the binaries so
+ that they default to using the desired heap size. PostgreSQL can
+ also be rebuilt, passing <literal>configure
+ LDFLAGS="-Wl,-bmaxdata:0x<replaceable>n</replaceable>0000000"</literal>
+ to achieve the same effect.
+ </para>
+
+ <para>
+ For a 64-bit build, set <envar>OBJECT_MODE</envar> to 64 and
+ pass <literal>CC="gcc -maix64"</literal>
+ and <literal>LDFLAGS="-Wl,-bbigtoc"</literal>
+ to <command>configure</command>. (Options for
+ <command>xlc</command> might differ.) If you omit the export of
+ <envar>OBJECT_MODE</envar>, your build may fail with linker errors. When
+ <envar>OBJECT_MODE</envar> is set, it tells AIX's build utilities
+ such as <command>ar</command>, <command>as</command>, and <command>ld</command> what
+ type of objects to default to handling.
+ </para>
+
+ <para>
+ By default, overcommit of paging space can happen. While we have
+ not seen this occur, AIX will kill processes when it runs out of
+ memory and the overcommit is accessed. The closest to this that
+ we have seen is fork failing because the system decided that
+ there was not enough memory for another process. Like many other
+ parts of AIX, the paging space allocation method and
+ out-of-memory kill is configurable on a system- or process-wide
+ basis if this becomes a problem.
+ </para>
+ </sect3>
+ </sect2>
+
<sect2 id="installation-notes-cygwin">
<title>Cygwin</title>
diff --git a/doc/src/sgml/runtime.sgml b/doc/src/sgml/runtime.sgml
index 6047b8171d..64753d9c01 100644
--- a/doc/src/sgml/runtime.sgml
+++ b/doc/src/sgml/runtime.sgml
@@ -891,6 +891,29 @@ psql: error: connection to server on socket "/tmp/.s.PGSQL.5432" failed: No such
<variablelist>
+ <varlistentry>
+ <term><systemitem class="osname">AIX</systemitem>
+ <indexterm><primary>AIX</primary><secondary>IPC configuration</secondary></indexterm>
+ </term>
+ <listitem>
+ <para>
+ It should not be necessary to do
+ any special configuration for such parameters as
+ <varname>SHMMAX</varname>, as it appears this is configured to
+ allow all memory to be used as shared memory. That is the
+ sort of configuration commonly used for other databases such
+ as <application>DB/2</application>.</para>
+
+ <para> It might, however, be necessary to modify the global
+ <command>ulimit</command> information in
+ <filename>/etc/security/limits</filename>, as the default hard
+ limits for file sizes (<varname>fsize</varname>) and numbers of
+ files (<varname>nofiles</varname>) might be too low.
+ </para>
+ </listitem>
+ </varlistentry>
+
+
<varlistentry>
<term><systemitem class="osname">FreeBSD</systemitem>
<indexterm><primary>FreeBSD</primary><secondary>IPC configuration</secondary></indexterm>
diff --git a/meson.build b/meson.build
index 1c0579d5a6..f1ac154cdc 100644
--- a/meson.build
+++ b/meson.build
@@ -196,7 +196,26 @@ endif
# that purpose.
portname = host_system
-if host_system == 'cygwin'
+if host_system == 'aix'
+ library_path_var = 'LIBPATH'
+
+ export_file_format = 'aix'
+ export_fmt = '-Wl,-bE:@0@'
+ mod_link_args_fmt = ['-Wl,-bI:@0@']
+ mod_link_with_dir = 'libdir'
+ mod_link_with_name = '@[email protected]'
+
+ # M:SRE sets a flag indicating that an object is a shared library. Seems to
+ # work in some circumstances without, but required in others.
+ ldflags_sl += '-Wl,-bM:SRE'
+ ldflags_be += '-Wl,-brtllib'
+
+ # Native memset() is faster, tested on:
+ # - AIX 5.1 and 5.2, XLC 6.0 (IBM's cc)
+ # - AIX 5.3 ML3, gcc 4.0.1
+ memset_loop_limit = 0
+
+elif host_system == 'cygwin'
sema_kind = 'unnamed_posix'
cppflags += '-D_GNU_SOURCE'
dlsuffix = '.dll'
@@ -1490,11 +1509,11 @@ sizeof_long = cc.sizeof('long', args: test_c_args)
cdata.set('SIZEOF_LONG', sizeof_long)
if sizeof_long == 8
cdata.set('HAVE_LONG_INT_64', 1)
- pg_int64_type = 'long int'
+ cdata.set('PG_INT64_TYPE', 'long int')
cdata.set_quoted('INT64_MODIFIER', 'l')
elif sizeof_long == 4 and cc.sizeof('long long', args: test_c_args) == 8
cdata.set('HAVE_LONG_LONG_INT_64', 1)
- pg_int64_type = 'long long int'
+ cdata.set('PG_INT64_TYPE', 'long long int')
cdata.set_quoted('INT64_MODIFIER', 'll')
else
error('do not know how to get a 64bit int')
@@ -1508,31 +1527,15 @@ endif
# Determine memory alignment requirements for the basic C data types.
alignof_types = ['short', 'int', 'long', 'double']
+maxalign = 0
foreach t : alignof_types
align = cc.alignment(t, args: test_c_args)
+ if maxalign < align
+ maxalign = align
+ endif
cdata.set('ALIGNOF_@0@'.format(t.to_upper()), align)
endforeach
-
-# Compute maximum alignment of any basic type.
-#
-# We require 'double' to have the strictest alignment among the basic types,
-# because otherwise the C ABI might impose 8-byte alignment on some of the
-# other C types that correspond to TYPALIGN_DOUBLE SQL types. That could
-# cause a mismatch between the tuple layout and the C struct layout of a
-# catalog tuple. We used to carefully order catalog columns such that any
-# fixed-width, attalign=4 columns were at offsets divisible by 8 regardless
-# of MAXIMUM_ALIGNOF to avoid that, but we no longer support any platforms
-# where TYPALIGN_DOUBLE != MAXIMUM_ALIGNOF.
-#
-# We assume without checking that int64's alignment is at least as strong
-# as long, char, short, or int. Note that we intentionally do not consider
-# any types wider than 64 bits, as allowing MAXIMUM_ALIGNOF to exceed 8
-# would be too much of a penalty for disk and memory space.
-alignof_double = cdata.get('ALIGNOF_DOUBLE')
-if cc.alignment(pg_int64_type, args: test_c_args) > alignof_double
- error('alignment of int64 is greater than the alignment of double')
-endif
-cdata.set('MAXIMUM_ALIGNOF', alignof_double)
+cdata.set('MAXIMUM_ALIGNOF', maxalign)
cdata.set('SIZEOF_VOID_P', cc.sizeof('void *', args: test_c_args))
cdata.set('SIZEOF_SIZE_T', cc.sizeof('size_t', args: test_c_args))
@@ -1581,7 +1584,7 @@ if cc.links('''
if not meson.is_cross_build()
r = cc.run('''
/* This must match the corresponding code in c.h: */
- #if defined(__GNUC__) || defined(__SUNPRO_C)
+ #if defined(__GNUC__) || defined(__SUNPRO_C) || defined(__IBMC__)
#define pg_attribute_aligned(a) __attribute__((aligned(a)))
#elif defined(_MSC_VER)
#define pg_attribute_aligned(a) __declspec(align(a))
@@ -2476,6 +2479,10 @@ endif
# conflict.
#
# We assume C99 support, so we don't need to make this conditional.
+#
+# XXX: Historically we allowed platforms to disable restrict in template
+# files, but that was only added for AIX when building with XLC, which we
+# don't support yet.
cdata.set('pg_restrict', '__restrict')
diff --git a/src/Makefile.shlib b/src/Makefile.shlib
index fa81f6ffdd..8ca51ca03f 100644
--- a/src/Makefile.shlib
+++ b/src/Makefile.shlib
@@ -106,6 +106,20 @@ ifdef SO_MAJOR_VERSION
override CPPFLAGS += -DSO_MAJOR_VERSION=$(SO_MAJOR_VERSION)
endif
+ifeq ($(PORTNAME), aix)
+ LINK.shared = $(COMPILER)
+ ifdef SO_MAJOR_VERSION
+ shlib = lib$(NAME)$(DLSUFFIX).$(SO_MAJOR_VERSION)
+ endif
+ haslibarule = yes
+ # $(exports_file) is also usable as an import file
+ exports_file = lib$(NAME).exp
+ BUILD.exports = ( echo '\#! $(shlib)'; $(AWK) '/^[^\#]/ {printf "%s\n",$$1}' $< ) > $@
+ ifneq (,$(SHLIB_EXPORTS))
+ LINK.shared += -Wl,-bE:$(exports_file)
+ endif
+endif
+
ifeq ($(PORTNAME), darwin)
ifdef soname
# linkable library
@@ -254,6 +268,14 @@ $(stlib): $(OBJS) | $(SHLIB_PREREQS)
touch $@
endif #haslibarule
+# AIX wraps shared libraries inside a static library, can be used both
+# for static and shared linking
+ifeq ($(PORTNAME), aix)
+$(stlib): $(shlib)
+ rm -f $(stlib)
+ $(AR) $(AROPT) $(stlib) $(shlib)
+endif # aix
+
ifeq (,$(filter cygwin win32,$(PORTNAME)))
# Normal case
@@ -267,8 +289,11 @@ ifneq ($(shlib), $(shlib_major))
endif
# Make sure we have a link to a name without any version numbers
ifneq ($(shlib), $(shlib_bare))
+# except on AIX, where that's not a thing
+ifneq ($(PORTNAME), aix)
rm -f $(shlib_bare)
$(LN_S) $(shlib) $(shlib_bare)
+endif # aix
endif # shlib_bare
endif # shlib_major
@@ -376,6 +401,9 @@ install-lib-static: $(stlib) installdirs-lib
install-lib-shared: $(shlib) installdirs-lib
ifdef soname
+# we don't install $(shlib) on AIX
+# (see http://archives.postgresql.org/message-id/52EF20B2E3209443BC37736D00C3C1380A6E79FE@EXADV1.host.magwien.gv.at)
+ifneq ($(PORTNAME), aix)
$(INSTALL_SHLIB) $< '$(DESTDIR)$(libdir)/$(shlib)'
ifneq ($(PORTNAME), cygwin)
ifneq ($(PORTNAME), win32)
@@ -391,6 +419,7 @@ ifneq ($(shlib), $(shlib_bare))
endif
endif # not win32
endif # not cygwin
+endif # not aix
ifneq (,$(findstring $(PORTNAME),win32 cygwin))
$(INSTALL_SHLIB) $< '$(DESTDIR)$(bindir)/$(shlib)'
endif
diff --git a/src/backend/Makefile b/src/backend/Makefile
index 6700aec039..954b14962f 100644
--- a/src/backend/Makefile
+++ b/src/backend/Makefile
@@ -62,12 +62,14 @@ all: submake-libpgport submake-catalog-headers submake-utils-headers postgres $(
ifneq ($(PORTNAME), cygwin)
ifneq ($(PORTNAME), win32)
+ifneq ($(PORTNAME), aix)
postgres: $(OBJS)
$(CC) $(CFLAGS) $(call expand_subsys,$^) $(LDFLAGS) $(LIBS) -o $@
endif
endif
+endif
ifeq ($(PORTNAME), cygwin)
@@ -94,6 +96,24 @@ libpostgres.a: postgres
endif # win32
+ifeq ($(PORTNAME), aix)
+
+postgres: $(POSTGRES_IMP)
+ $(CC) $(CFLAGS) $(call expand_subsys,$(OBJS)) $(LDFLAGS) -Wl,-bE:$(top_builddir)/src/backend/$(POSTGRES_IMP) $(LIBS) -Wl,-brtllib -o $@
+
+# Linking to a single .o with -r is a lot faster than building a .a or passing
+# all objects to MKLDEXPORT.
+#
+# It looks alluring to use $(CC) -r instead of ld -r, but that doesn't
+# trivially work with gcc, due to gcc specific static libraries linked in with
+# -r.
+$(POSTGRES_IMP): $(OBJS)
+ ld -r -o SUBSYS.o $(call expand_subsys,$^)
+ $(MKLDEXPORT) SUBSYS.o . > $@
+ @rm -f SUBSYS.o
+
+endif # aix
+
$(top_builddir)/src/port/libpgport_srv.a: | submake-libpgport
diff --git a/src/backend/meson.build b/src/backend/meson.build
index 436c04af08..8767aaba67 100644
--- a/src/backend/meson.build
+++ b/src/backend/meson.build
@@ -91,6 +91,21 @@ if cc.get_id() == 'msvc'
# be restricted to b_pch=true.
backend_link_with += postgres_lib
+elif host_system == 'aix'
+ # The '.' argument leads mkldexport.sh to emit "#! .", which refers to the
+ # main executable, allowing extension libraries to resolve their undefined
+ # symbols to symbols in the postgres binary.
+ postgres_imp = custom_target('postgres.imp',
+ command: [files('port/aix/mkldexport.sh'), '@INPUT@', '.'],
+ input: postgres_lib,
+ output: 'postgres.imp',
+ capture: true,
+ install: true,
+ install_dir: dir_lib,
+ build_by_default: false,
+ )
+ backend_link_args += '-Wl,-bE:@0@'.format(postgres_imp.full_path())
+ backend_link_depends += postgres_imp
endif
backend_input = []
diff --git a/src/backend/port/aix/mkldexport.sh b/src/backend/port/aix/mkldexport.sh
new file mode 100755
index 0000000000..adf3793e86
--- /dev/null
+++ b/src/backend/port/aix/mkldexport.sh
@@ -0,0 +1,61 @@
+#!/bin/sh
+#
+# mkldexport
+# create an AIX exports file from an object file
+#
+# src/backend/port/aix/mkldexport.sh
+#
+# Usage:
+# mkldexport objectfile [location]
+# where
+# objectfile is the current location of the object file.
+# location is the eventual (installed) location of the
+# object file (if different from the current
+# working directory).
+#
+# [This file comes from the Postgres 4.2 distribution. - ay 7/95]
+#
+# Header: /usr/local/devel/postgres/src/tools/mkldexport/RCS/mkldexport.sh,v 1.2 1994/03/13 04:59:12 aoki Exp
+#
+
+# setting this to nm -B might be better
+# ... due to changes in AIX 4.x ...
+# ... let us search in different directories - Gerhard Reithofer
+if [ -x /usr/ucb/nm ]
+then NM=/usr/ucb/nm
+elif [ -x /usr/bin/nm ]
+then NM=/usr/bin/nm
+elif [ -x /usr/ccs/bin/nm ]
+then NM=/usr/ccs/bin/nm
+elif [ -x /usr/usg/bin/nm ]
+then NM=/usr/usg/bin/nm
+else echo "Fatal error: cannot find `nm' ... please check your installation."
+ exit 1
+fi
+
+CMDNAME=`basename $0`
+if [ -z "$1" ]; then
+ echo "Usage: $CMDNAME object [location]"
+ exit 1
+fi
+OBJNAME=`basename $1`
+if [ "`basename $OBJNAME`" != "`basename $OBJNAME .o`" ]; then
+ OBJNAME=`basename $OBJNAME .o`.so
+fi
+if [ -z "$2" ]; then
+ echo '#!'
+else
+ if [ "$2" = "." ]; then
+ # for the base executable (AIX 4.2 and up)
+ echo '#! .'
+ else
+ echo '#!' $2
+ fi
+fi
+$NM -BCg $1 | \
+ egrep ' [TDB] ' | \
+ sed -e 's/.* //' | \
+ egrep -v '\$' | \
+ sed -e 's/^[.]//' | \
+ sort | \
+ uniq
diff --git a/src/backend/storage/buffer/bufmgr.c b/src/backend/storage/buffer/bufmgr.c
index 49637284f9..bade061271 100644
--- a/src/backend/storage/buffer/bufmgr.c
+++ b/src/backend/storage/buffer/bufmgr.c
@@ -788,7 +788,7 @@ ReadBuffer(Relation reln, BlockNumber blockNum)
* If strategy is not NULL, a nondefault buffer access strategy is used.
* See buffer/README for details.
*/
-inline Buffer
+Buffer
ReadBufferExtended(Relation reln, ForkNumber forkNum, BlockNumber blockNum,
ReadBufferMode mode, BufferAccessStrategy strategy)
{
diff --git a/src/backend/utils/error/elog.c b/src/backend/utils/error/elog.c
index d91a85cb2d..7b51e94f4a 100644
--- a/src/backend/utils/error/elog.c
+++ b/src/backend/utils/error/elog.c
@@ -908,7 +908,9 @@ errcode_for_file_access(void)
/* Wrong object type or state */
case ENOTDIR: /* Not a directory */
case EISDIR: /* Is a directory */
+#if defined(ENOTEMPTY) && (ENOTEMPTY != EEXIST) /* same code on AIX */
case ENOTEMPTY: /* Directory not empty */
+#endif
edata->sqlerrcode = ERRCODE_WRONG_OBJECT_TYPE;
break;
diff --git a/src/backend/utils/misc/ps_status.c b/src/backend/utils/misc/ps_status.c
index 9da6377402..532eac31b4 100644
--- a/src/backend/utils/misc/ps_status.c
+++ b/src/backend/utils/misc/ps_status.c
@@ -50,7 +50,7 @@ bool update_process_title = DEFAULT_UPDATE_PROCESS_TITLE;
#define PS_USE_SETPROCTITLE_FAST
#elif defined(HAVE_SETPROCTITLE)
#define PS_USE_SETPROCTITLE
-#elif defined(__linux__) || defined(__sun) || defined(__darwin__)
+#elif defined(__linux__) || defined(_AIX) || defined(__sun) || defined(__darwin__)
#define PS_USE_CLOBBER_ARGV
#elif defined(WIN32)
#define PS_USE_WIN32
@@ -60,7 +60,7 @@ bool update_process_title = DEFAULT_UPDATE_PROCESS_TITLE;
/* Different systems want the buffer padded differently */
-#if defined(__linux__) || defined(__darwin__)
+#if defined(_AIX) || defined(__linux__) || defined(__darwin__)
#define PS_PADDING '\0'
#else
#define PS_PADDING ' '
diff --git a/src/bin/pg_basebackup/t/010_pg_basebackup.pl b/src/bin/pg_basebackup/t/010_pg_basebackup.pl
index 2d4b75a6fe..ce936959c1 100644
--- a/src/bin/pg_basebackup/t/010_pg_basebackup.pl
+++ b/src/bin/pg_basebackup/t/010_pg_basebackup.pl
@@ -401,7 +401,8 @@ SKIP:
{
my $tar = $ENV{TAR};
# don't check for a working tar here, to accommodate various odd
- # cases. If tar doesn't work the init_from_backup below will fail.
+ # cases such as AIX. If tar doesn't work the init_from_backup below
+ # will fail.
skip "no tar program available", 1
if (!defined $tar || $tar eq '');
diff --git a/src/bin/pg_verifybackup/t/008_untar.pl b/src/bin/pg_verifybackup/t/008_untar.pl
index 7a09f3b75b..30d9f3f7f0 100644
--- a/src/bin/pg_verifybackup/t/008_untar.pl
+++ b/src/bin/pg_verifybackup/t/008_untar.pl
@@ -104,7 +104,8 @@ for my $tc (@test_configuration)
{
my $tar = $ENV{TAR};
# don't check for a working tar here, to accommodate various odd
- # cases. If tar doesn't work the init_from_backup below will fail.
+ # cases such as AIX. If tar doesn't work the init_from_backup below
+ # will fail.
skip "no tar program available", 1
if (!defined $tar || $tar eq '');
diff --git a/src/bin/pg_verifybackup/t/010_client_untar.pl b/src/bin/pg_verifybackup/t/010_client_untar.pl
index 8c076d46de..45010d79ac 100644
--- a/src/bin/pg_verifybackup/t/010_client_untar.pl
+++ b/src/bin/pg_verifybackup/t/010_client_untar.pl
@@ -134,7 +134,8 @@ for my $tc (@test_configuration)
{
my $tar = $ENV{TAR};
# don't check for a working tar here, to accommodate various odd
- # cases. If tar doesn't work the init_from_backup below will fail.
+ # cases such as AIX. If tar doesn't work the init_from_backup below
+ # will fail.
skip "no tar program available", 1
if (!defined $tar || $tar eq '');
diff --git a/src/include/c.h b/src/include/c.h
index dc1841346c..b667ac54a0 100644
--- a/src/include/c.h
+++ b/src/include/c.h
@@ -105,6 +105,8 @@
* GCC: https://gcc.gnu.org/onlinedocs/gcc/Type-Attributes.html
* Clang: https://clang.llvm.org/docs/AttributeReference.html
* Sunpro: https://docs.oracle.com/cd/E18659_01/html/821-1384/gjzke.html
+ * XLC: https://www.ibm.com/support/knowledgecenter/SSGH2K_13.1.2/com.ibm.xlc131.aix.doc/language_ref/function_attributes.html
+ * XLC: https://www.ibm.com/support/knowledgecenter/SSGH2K_13.1.2/com.ibm.xlc131.aix.doc/language_ref/type_attrib.html
*/
/*
@@ -182,8 +184,8 @@
#define PG_USED_FOR_ASSERTS_ONLY pg_attribute_unused()
#endif
-/* GCC supports format attributes */
-#if defined(__GNUC__)
+/* GCC and XLC support format attributes */
+#if defined(__GNUC__) || defined(__IBMC__)
#define pg_attribute_format_arg(a) __attribute__((format_arg(a)))
#define pg_attribute_printf(f,a) __attribute__((format(PG_PRINTF_ATTRIBUTE, f, a)))
#else
@@ -191,8 +193,8 @@
#define pg_attribute_printf(f,a)
#endif
-/* GCC and Sunpro support aligned, packed and noreturn */
-#if defined(__GNUC__) || defined(__SUNPRO_C)
+/* GCC, Sunpro and XLC support aligned, packed and noreturn */
+#if defined(__GNUC__) || defined(__SUNPRO_C) || defined(__IBMC__)
#define pg_attribute_aligned(a) __attribute__((aligned(a)))
#define pg_attribute_noreturn() __attribute__((noreturn))
#define pg_attribute_packed() __attribute__((packed))
@@ -223,8 +225,8 @@
* choose not to. But, if possible, don't force inlining in unoptimized
* debug builds.
*/
-#if (defined(__GNUC__) && __GNUC__ > 3 && defined(__OPTIMIZE__)) || defined(__SUNPRO_C)
-/* GCC > 3 and Sunpro support always_inline via __attribute__ */
+#if (defined(__GNUC__) && __GNUC__ > 3 && defined(__OPTIMIZE__)) || defined(__SUNPRO_C) || defined(__IBMC__)
+/* GCC > 3, Sunpro and XLC support always_inline via __attribute__ */
#define pg_attribute_always_inline __attribute__((always_inline)) inline
#elif defined(_MSC_VER)
/* MSVC has a special keyword for this */
@@ -240,8 +242,8 @@
* for proper cost attribution. Note that unlike the pg_attribute_XXX macros
* above, this should be placed before the function's return type and name.
*/
-/* GCC and Sunpro support noinline via __attribute__ */
-#if (defined(__GNUC__) && __GNUC__ > 2) || defined(__SUNPRO_C)
+/* GCC, Sunpro and XLC support noinline via __attribute__ */
+#if (defined(__GNUC__) && __GNUC__ > 2) || defined(__SUNPRO_C) || defined(__IBMC__)
#define pg_noinline __attribute__((noinline))
/* msvc via declspec */
#elif defined(_MSC_VER)
diff --git a/src/include/port/aix.h b/src/include/port/aix.h
new file mode 100644
index 0000000000..5b1159c578
--- /dev/null
+++ b/src/include/port/aix.h
@@ -0,0 +1,14 @@
+/*
+ * src/include/port/aix.h
+ */
+#define CLASS_CONFLICT
+#define DISABLE_XOPEN_NLS
+
+/*
+ * "IBM XL C/C++ for AIX, V12.1" miscompiles, for 32-bit, some inline
+ * expansions of ginCompareItemPointers() "long long" arithmetic. To take
+ * advantage of inlining, build a 64-bit PostgreSQL.
+ */
+#if defined(__ILP32__) && defined(__IBMC__)
+#define PG_FORCE_DISABLE_INLINE
+#endif
diff --git a/src/include/port/atomics.h b/src/include/port/atomics.h
index 78987f3154..5b2b70fe5f 100644
--- a/src/include/port/atomics.h
+++ b/src/include/port/atomics.h
@@ -84,9 +84,11 @@
* using compiler intrinsics are a good idea.
*/
/*
- * gcc or compatible, including clang and icc.
+ * gcc or compatible, including clang and icc. Exclude xlc. The ppc64le "IBM
+ * XL C/C++ for Linux, V13.1.2" emulates gcc, but __sync_lock_test_and_set()
+ * of one-byte types elicits SIGSEGV. That bug was gone by V13.1.5 (2016-12).
*/
-#if defined(__GNUC__) || defined(__INTEL_COMPILER)
+#if (defined(__GNUC__) || defined(__INTEL_COMPILER)) && !(defined(__IBMC__) || defined(__IBMCPP__))
#include "port/atomics/generic-gcc.h"
#elif defined(_MSC_VER)
#include "port/atomics/generic-msvc.h"
diff --git a/src/include/storage/s_lock.h b/src/include/storage/s_lock.h
index 29ac6cdcd9..69582f4ae7 100644
--- a/src/include/storage/s_lock.h
+++ b/src/include/storage/s_lock.h
@@ -414,6 +414,12 @@ typedef unsigned int slock_t;
* an isync is a sufficient synchronization barrier after a lwarx/stwcx loop.
* But if the spinlock is in ordinary memory, we can use lwsync instead for
* better performance.
+ *
+ * Ordinarily, we'd code the branches here using GNU-style local symbols, that
+ * is "1f" referencing "1:" and so on. But some people run gcc on AIX with
+ * IBM's assembler as backend, and IBM's assembler doesn't do local symbols.
+ * So hand-code the branch offsets; fortunately, all PPC instructions are
+ * exactly 4 bytes each, so it's not too hard to count.
*/
static __inline__ int
tas(volatile slock_t *lock)
@@ -424,17 +430,15 @@ tas(volatile slock_t *lock)
__asm__ __volatile__(
" lwarx %0,0,%3,1 \n"
" cmpwi %0,0 \n"
-" bne 1f \n"
+" bne $+16 \n" /* branch to li %1,1 */
" addi %0,%0,1 \n"
" stwcx. %0,0,%3 \n"
-" beq 2f \n"
-"1: \n"
+" beq $+12 \n" /* branch to lwsync */
" li %1,1 \n"
-" b 3f \n"
-"2: \n"
+" b $+12 \n" /* branch to end of asm sequence */
" lwsync \n"
" li %1,0 \n"
-"3: \n"
+
: "=&b"(_t), "=r"(_res), "+m"(*lock)
: "r"(lock)
: "memory", "cc");
@@ -662,6 +666,21 @@ tas(volatile slock_t *lock)
#if !defined(HAS_TEST_AND_SET) /* We didn't trigger above, let's try here */
+#if defined(_AIX) /* AIX */
+/*
+ * AIX (POWER)
+ */
+#define HAS_TEST_AND_SET
+
+#include <sys/atomic_op.h>
+
+typedef int slock_t;
+
+#define TAS(lock) _check_lock((slock_t *) (lock), 0, 1)
+#define S_UNLOCK(lock) _clear_lock((slock_t *) (lock), 0)
+#endif /* _AIX */
+
+
/* These are in sunstudio_(sparc|x86).s */
#if defined(__SUNPRO_C) && (defined(__i386) || defined(__x86_64__) || defined(__sparc__) || defined(__sparc))
diff --git a/src/interfaces/libpq/Makefile b/src/interfaces/libpq/Makefile
index b36a765764..154429d4d1 100644
--- a/src/interfaces/libpq/Makefile
+++ b/src/interfaces/libpq/Makefile
@@ -114,7 +114,7 @@ backend_src = $(top_srcdir)/src/backend
# coding rule.
libpq-refs-stamp: $(shlib)
ifneq ($(enable_coverage), yes)
-ifeq (,$(filter solaris,$(PORTNAME)))
+ifeq (,$(filter aix solaris,$(PORTNAME)))
@if nm -A -u $< 2>/dev/null | grep -v -e __cxa_atexit -e __tsan_func_exit | grep exit; then \
echo 'libpq must not be calling any function which invokes exit'; exit 1; \
fi
diff --git a/src/interfaces/libpq/meson.build b/src/interfaces/libpq/meson.build
index ed2a4048d1..7e2017daf0 100644
--- a/src/interfaces/libpq/meson.build
+++ b/src/interfaces/libpq/meson.build
@@ -54,8 +54,9 @@ libpq_c_args = ['-DSO_MAJOR_VERSION=5']
# libpq_st, and {pgport,common}_shlib for libpq_sh
#
# We could try to avoid building the source files twice, but it probably adds
-# more complexity than its worth (reusing object files requires also linking
-# to the library on windows or breaks precompiled headers).
+# more complexity than its worth (AIX doesn't support link_whole yet, reusing
+# object files requires also linking to the library on windows or breaks
+# precompiled headers).
libpq_st = static_library('libpq',
libpq_sources,
include_directories: [libpq_inc],
diff --git a/src/makefiles/Makefile.aix b/src/makefiles/Makefile.aix
new file mode 100644
index 0000000000..dd16a7a037
--- /dev/null
+++ b/src/makefiles/Makefile.aix
@@ -0,0 +1,39 @@
+# MAKE_EXPORTS is required for svr4 loaders that want a file of
+# symbol names to tell them what to export/import.
+MAKE_EXPORTS= true
+
+# -blibpath must contain ALL directories where we should look for libraries
+libpath := $(shell echo $(subst -L,:,$(filter -L/%,$(LDFLAGS))) | sed -e's/ //g'):/usr/lib:/lib
+
+# when building with gcc, need to make sure that libgcc can be found
+ifeq ($(GCC), yes)
+libpath := $(libpath):$(dir $(shell gcc -print-libgcc-file-name))
+endif
+
+rpath = -Wl,-blibpath:'$(rpathdir)$(libpath)'
+
+LDFLAGS_SL += -Wl,-bnoentry -Wl,-H512 -Wl,-bM:SRE
+
+# gcc needs to know it's building a shared lib, otherwise it'll not emit
+# correct code / link to the right support libraries
+ifeq ($(GCC), yes)
+LDFLAGS_SL += -shared
+endif
+
+# env var name to use in place of LD_LIBRARY_PATH
+ld_library_path_var = LIBPATH
+
+
+POSTGRES_IMP= postgres.imp
+
+ifdef PGXS
+BE_DLLLIBS= -Wl,-bI:$(pkglibdir)/$(POSTGRES_IMP)
+else
+BE_DLLLIBS= -Wl,-bI:$(top_builddir)/src/backend/$(POSTGRES_IMP)
+endif
+
+MKLDEXPORT_DIR=src/backend/port/aix
+MKLDEXPORT=$(top_srcdir)/$(MKLDEXPORT_DIR)/mkldexport.sh
+
+%$(DLSUFFIX): %.o
+ $(CC) $(CFLAGS) $*.o $(LDFLAGS) $(LDFLAGS_SL) -o $@ $(BE_DLLLIBS)
diff --git a/src/port/README b/src/port/README
index ed5c54a72f..97f18a6233 100644
--- a/src/port/README
+++ b/src/port/README
@@ -28,5 +28,5 @@ applications.
from libpgport are linked first. This avoids having applications
dependent on symbols that are _used_ by libpq, but not intended to be
exported by libpq. libpq's libpgport usage changes over time, so such a
-dependency is a problem. Windows, Linux, and macOS use an export
+dependency is a problem. Windows, Linux, AIX, and macOS use an export
list to control the symbols exported by libpq.
diff --git a/src/port/strerror.c b/src/port/strerror.c
index 4918ba821c..1070a49802 100644
--- a/src/port/strerror.c
+++ b/src/port/strerror.c
@@ -214,8 +214,10 @@ get_errno_symbol(int errnum)
return "ENOTCONN";
case ENOTDIR:
return "ENOTDIR";
+#if defined(ENOTEMPTY) && (ENOTEMPTY != EEXIST) /* same code on AIX */
case ENOTEMPTY:
return "ENOTEMPTY";
+#endif
case ENOTSOCK:
return "ENOTSOCK";
#ifdef ENOTSUP
diff --git a/src/template/aix b/src/template/aix
new file mode 100644
index 0000000000..47fa8990a7
--- /dev/null
+++ b/src/template/aix
@@ -0,0 +1,25 @@
+# src/template/aix
+
+# Set default options if using xlc. This formerly included -qsrcmsg, but that
+# option elicits internal compiler errors from xlc v16.1.0. Note: configure
+# will add -qnoansialias if the compiler accepts it, even if user specifies a
+# non-default CFLAGS setting.
+if test "$GCC" != yes ; then
+ case $host_os in
+ *)
+ CFLAGS="-O2 -qmaxmem=16384"
+ ;;
+ esac
+
+ # Due to a compiler bug, see [email protected] for details,
+ # force restrict not to be used when compiling with xlc.
+ FORCE_DISABLE_RESTRICT=yes
+fi
+
+# Extra CFLAGS for code that will go into a shared library
+CFLAGS_SL=""
+
+# Native memset() is faster, tested on:
+# AIX 5.1 and 5.2, XLC 6.0 (IBM's cc)
+# AIX 5.3 ML3, gcc 4.0.1
+MEMSET_LOOP_LIMIT=0
diff --git a/src/test/regress/Makefile b/src/test/regress/Makefile
index 6409a485e8..7c665ff892 100644
--- a/src/test/regress/Makefile
+++ b/src/test/regress/Makefile
@@ -7,6 +7,11 @@
# GNU make uses a make file named "GNUmakefile" in preference to "Makefile"
# if it exists. Postgres is shipped with a "GNUmakefile".
+
+# AIX make defaults to building *every* target of the first rule. Start with
+# a single-target, empty rule to make the other targets non-default.
+all:
+
all install clean check installcheck:
@echo "You must use GNU make to use Postgres. It may be installed"
@echo "on your system with the name 'gmake'."
diff --git a/src/test/regress/expected/sanity_check.out b/src/test/regress/expected/sanity_check.out
index 8370c1561c..c5c675b750 100644
--- a/src/test/regress/expected/sanity_check.out
+++ b/src/test/regress/expected/sanity_check.out
@@ -25,3 +25,32 @@ SELECT relname, relkind
---------+---------
(0 rows)
+--
+-- When ALIGNOF_DOUBLE==4 (e.g. AIX), the C ABI may impose 8-byte alignment on
+-- some of the C types that correspond to TYPALIGN_DOUBLE SQL types. To ensure
+-- catalog C struct layout matches catalog tuple layout, arrange for the tuple
+-- offset of each fixed-width, attalign='d' catalog column to be divisible by 8
+-- unconditionally. Keep such columns before the first NameData column of the
+-- catalog, since packagers can override NAMEDATALEN to an odd number.
+--
+WITH check_columns AS (
+ SELECT relname, attname,
+ array(
+ SELECT t.oid
+ FROM pg_type t JOIN pg_attribute pa ON t.oid = pa.atttypid
+ WHERE pa.attrelid = a.attrelid AND
+ pa.attnum > 0 AND pa.attnum < a.attnum
+ ORDER BY pa.attnum) AS coltypes
+ FROM pg_attribute a JOIN pg_class c ON c.oid = attrelid
+ JOIN pg_namespace n ON c.relnamespace = n.oid
+ WHERE attalign = 'd' AND relkind = 'r' AND
+ attnotnull AND attlen <> -1 AND n.nspname = 'pg_catalog'
+)
+SELECT relname, attname, coltypes, get_columns_length(coltypes)
+ FROM check_columns
+ WHERE get_columns_length(coltypes) % 8 != 0 OR
+ 'name'::regtype::oid = ANY(coltypes);
+ relname | attname | coltypes | get_columns_length
+---------+---------+----------+--------------------
+(0 rows)
+
diff --git a/src/test/regress/expected/test_setup.out b/src/test/regress/expected/test_setup.out
index 3d0eeec996..5d9e6bf12b 100644
--- a/src/test/regress/expected/test_setup.out
+++ b/src/test/regress/expected/test_setup.out
@@ -209,6 +209,10 @@ CREATE FUNCTION ttdummy ()
RETURNS trigger
AS :'regresslib'
LANGUAGE C;
+CREATE FUNCTION get_columns_length(oid[])
+ RETURNS int
+ AS :'regresslib'
+ LANGUAGE C STRICT STABLE PARALLEL SAFE;
-- Use hand-rolled hash functions and operator classes to get predictable
-- result on different machines. The hash function for int4 simply returns
-- the sum of the values passed to it and the one for text returns the length
diff --git a/src/test/regress/regress.c b/src/test/regress/regress.c
index deffaea578..cc633864d7 100644
--- a/src/test/regress/regress.c
+++ b/src/test/regress/regress.c
@@ -1221,3 +1221,43 @@ binary_coercible(PG_FUNCTION_ARGS)
PG_RETURN_BOOL(IsBinaryCoercible(srctype, targettype));
}
+
+/*
+ * Return the length of the portion of a tuple consisting of the given array
+ * of data types. The input data types must be fixed-length data types.
+ */
+PG_FUNCTION_INFO_V1(get_columns_length);
+Datum
+get_columns_length(PG_FUNCTION_ARGS)
+{
+ ArrayType *ta = PG_GETARG_ARRAYTYPE_P(0);
+ Oid *type_oids;
+ int ntypes;
+ int column_offset = 0;
+
+ if (ARR_HASNULL(ta) && array_contains_nulls(ta))
+ elog(ERROR, "argument must not contain nulls");
+
+ if (ARR_NDIM(ta) > 1)
+ elog(ERROR, "argument must be empty or one-dimensional array");
+
+ type_oids = (Oid *) ARR_DATA_PTR(ta);
+ ntypes = ArrayGetNItems(ARR_NDIM(ta), ARR_DIMS(ta));
+ for (int i = 0; i < ntypes; i++)
+ {
+ Oid typeoid = type_oids[i];
+ int16 typlen;
+ bool typbyval;
+ char typalign;
+
+ get_typlenbyvalalign(typeoid, &typlen, &typbyval, &typalign);
+
+ /* the data type must be fixed-length */
+ if (typlen < 0)
+ elog(ERROR, "type %u is not fixed-length data type", typeoid);
+
+ column_offset = att_align_nominal(column_offset + typlen, typalign);
+ }
+
+ PG_RETURN_INT32(column_offset);
+}
diff --git a/src/test/regress/sql/sanity_check.sql b/src/test/regress/sql/sanity_check.sql
index 162e5324b5..7f338d191c 100644
--- a/src/test/regress/sql/sanity_check.sql
+++ b/src/test/regress/sql/sanity_check.sql
@@ -19,3 +19,29 @@ SELECT relname, relkind
FROM pg_class
WHERE relkind IN ('v', 'c', 'f', 'p', 'I')
AND relfilenode <> 0;
+
+--
+-- When ALIGNOF_DOUBLE==4 (e.g. AIX), the C ABI may impose 8-byte alignment on
+-- some of the C types that correspond to TYPALIGN_DOUBLE SQL types. To ensure
+-- catalog C struct layout matches catalog tuple layout, arrange for the tuple
+-- offset of each fixed-width, attalign='d' catalog column to be divisible by 8
+-- unconditionally. Keep such columns before the first NameData column of the
+-- catalog, since packagers can override NAMEDATALEN to an odd number.
+--
+WITH check_columns AS (
+ SELECT relname, attname,
+ array(
+ SELECT t.oid
+ FROM pg_type t JOIN pg_attribute pa ON t.oid = pa.atttypid
+ WHERE pa.attrelid = a.attrelid AND
+ pa.attnum > 0 AND pa.attnum < a.attnum
+ ORDER BY pa.attnum) AS coltypes
+ FROM pg_attribute a JOIN pg_class c ON c.oid = attrelid
+ JOIN pg_namespace n ON c.relnamespace = n.oid
+ WHERE attalign = 'd' AND relkind = 'r' AND
+ attnotnull AND attlen <> -1 AND n.nspname = 'pg_catalog'
+)
+SELECT relname, attname, coltypes, get_columns_length(coltypes)
+ FROM check_columns
+ WHERE get_columns_length(coltypes) % 8 != 0 OR
+ 'name'::regtype::oid = ANY(coltypes);
diff --git a/src/test/regress/sql/test_setup.sql b/src/test/regress/sql/test_setup.sql
index 06b0e2121f..1b2d434683 100644
--- a/src/test/regress/sql/test_setup.sql
+++ b/src/test/regress/sql/test_setup.sql
@@ -257,6 +257,11 @@ CREATE FUNCTION ttdummy ()
AS :'regresslib'
LANGUAGE C;
+CREATE FUNCTION get_columns_length(oid[])
+ RETURNS int
+ AS :'regresslib'
+ LANGUAGE C STRICT STABLE PARALLEL SAFE;
+
-- Use hand-rolled hash functions and operator classes to get predictable
-- result on different machines. The hash function for int4 simply returns
-- the sum of the values passed to it and the one for text returns the length
diff --git a/src/tools/gen_export.pl b/src/tools/gen_export.pl
index d9fdaaaf6d..888c8a197a 100644
--- a/src/tools/gen_export.pl
+++ b/src/tools/gen_export.pl
@@ -16,11 +16,12 @@ GetOptions(
'input:s' => \$input,
'output:s' => \$output) or die "wrong arguments";
-if (not( $format eq 'darwin'
+if (not( $format eq 'aix'
+ or $format eq 'darwin'
or $format eq 'gnu'
or $format eq 'win'))
{
- die "$0: $format is not yet handled (only darwin, gnu, win are)\n";
+ die "$0: $format is not yet handled (only aix, darwin, gnu, win are)\n";
}
open(my $input_handle, '<', $input)
@@ -55,7 +56,11 @@ while (<$input_handle>)
}
elsif (/^(\S+)\s+(\S+)/)
{
- if ($format eq 'darwin')
+ if ($format eq 'aix')
+ {
+ print $output_handle "$1\n";
+ }
+ elsif ($format eq 'darwin')
{
print $output_handle "_$1\n";
}
diff --git a/src/tools/pginclude/headerscheck b/src/tools/pginclude/headerscheck
index 4a157d0a5f..cfd8c6896c 100755
--- a/src/tools/pginclude/headerscheck
+++ b/src/tools/pginclude/headerscheck
@@ -85,6 +85,7 @@ do
# These files are platform-specific, and c.h will include the
# one that's relevant for our current platform anyway.
+ test "$f" = src/include/port/aix.h && continue
test "$f" = src/include/port/cygwin.h && continue
test "$f" = src/include/port/darwin.h && continue
test "$f" = src/include/port/freebsd.h && continue
--
2.41.0
^ permalink raw reply [nested|flat] 33+ messages in thread
end of thread, other threads:[~2024-05-22 16:15 UTC | newest]
Thread overview: 33+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2024-03-29 03:14 Re: AIX support Thomas Munro <[email protected]>
2024-03-29 03:33 ` Tom Lane <[email protected]>
2024-04-05 16:12 ` Sriram RK <[email protected]>
2024-04-05 17:26 ` Noah Misch <[email protected]>
2024-04-18 11:15 ` Sriram RK <[email protected]>
2024-04-18 11:25 ` Heikki Linnakangas <[email protected]>
2024-04-18 11:57 ` Sriram RK <[email protected]>
2024-04-18 18:01 ` Andres Freund <[email protected]>
2024-04-19 00:40 ` Thomas Munro <[email protected]>
2024-04-19 11:04 ` Sriram RK <[email protected]>
2024-04-20 15:42 ` Peter Eisentraut <[email protected]>
2024-04-20 16:25 ` Tom Lane <[email protected]>
2024-04-22 10:12 ` Sriram RK <[email protected]>
2024-04-25 03:39 ` Bruce Momjian <[email protected]>
2024-04-25 04:06 ` Michael Paquier <[email protected]>
2024-04-25 04:20 ` Tom Lane <[email protected]>
2024-04-25 04:45 ` Michael Paquier <[email protected]>
2024-04-26 17:30 ` Sriram RK <[email protected]>
2024-05-04 16:01 ` Sriram RK <[email protected]>
2024-05-06 14:12 ` Sriram RK <[email protected]>
2024-05-08 11:39 ` Sriram RK <[email protected]>
2024-05-08 13:44 ` Peter Eisentraut <[email protected]>
2024-05-08 14:06 ` Bruce Momjian <[email protected]>
2024-05-15 15:33 ` Sriram RK <[email protected]>
2024-05-15 15:52 ` Noah Misch <[email protected]>
2024-05-15 16:22 ` Sriram RK <[email protected]>
2024-05-16 14:17 ` Sriram RK <[email protected]>
2024-05-16 14:30 ` Alvaro Herrera <[email protected]>
2024-05-22 16:15 ` Sriram RK <[email protected]>
2024-04-25 08:03 ` Peter Eisentraut <[email protected]>
2024-04-25 13:54 ` Tom Lane <[email protected]>
2024-04-26 17:06 ` Bruce Momjian <[email protected]>
2024-04-22 14:54 ` Tristan Partin <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox