We are continuing to work on the changes…
> Do you still care about 32-bit binaries on AIX? If not, let's make that
> the default in configure or a check for it, and remove the instructions
> on building 32-bit binaries from the docs.
As most of the products are moving towards 64bit, we
On 19/06/2024 17:55, Srirama Kucherlapati wrote:
+/* Commenting for XLC
+ * "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__)
com
, postgres-ibm-...@wwpdl.vnet.ibm.com
Subject: [EXTERNAL] Re: AIX support
On 19/06/2024 17:55, Srirama Kucherlapati wrote:
> +/* Commenting for XLC
> + * "IBM XL C/C++ for AIX, V12.1" miscompiles, for 32-bit, some inline
> + * expansions of ginCompareItemPointers() "long long&
Hi Team,
Please find the attached patch, which resumes the AIX support with gcc alone.
We have
removed changes wrt to XLC on AIX.
We are also continuing to work on the XLC and IBM-clang(openXLC) specific patch
as well.
Once we get an approval for the above patch we can submit a subsequent patch
Hi Laurenz, we are working on the other file changes, we shall post you the
updates soon.
Warm regards,
Sriram.
On Fri, 2024-06-07 at 16:30 +, Srirama Kucherlapati wrote:
> Hi Team, We are pursuing to trim the changes wrt AIX. As of now we trimmed
> the changes with respect to XLC and currently with trimmed changes the
> buildfarm script passed (build and all the regression tests)
> The XLC changes were
Hi Team, We are pursuing to trim the changes wrt AIX. As of now we trimmed
the changes with respect to XLC and currently with trimmed changes the
buildfarm script passed (build and all the regression tests)
The XLC changes were trimmed only in the below file
modified: configure
modified:
On Thu, May 23, 2024 at 07:03:20PM +0300, Heikki Linnakangas wrote:
> > Can you provide some more details on the expectations here?
>
> Smallest possible patch that makes Postgres work on AIX again.
>
> Perhaps start with the patch you posted yesterday, but remove hunks from it
> one by one, to
On 23/05/2024 18:36, Srirama Kucherlapati wrote:
Hi Peter, thanks for your feedback.
We are eager to extend our support in resolving the issues specific
to AIX or corresponding compilers (XLC and cLang).
But as there are no issues with the patch after reverting the
changes(with the latest
Hi Peter, thanks for your feedback.
We are eager to extend our support in resolving the issues specific to AIX or
corresponding
compilers (XLC and cLang).
But as there are no issues with the patch after reverting the changes(with the
latest compilers
gcc12 and xlc-16.0.1.18), we were wondering
On 22.05.24 18:15, Sriram RK wrote:
Please find the attached patch.
Apart from the AIX specific changes, there is a minor change in this
file wrt to XLC, below is the error for which we removed inline.
Later, the build and tests passed for both XLC(16.1.0.18) and gcc(12) as
well.
I think
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
On 2024-May-16, Sriram RK wrote:
> Hi Team,
>
> We have an update wrt to the PG17 AIX port.
>
> We have reverted the changes specific to AIX (that were removed in
> 0b16bb8776bb8) to the latest PG17 (head).
>
> The Buildfarm succeeded for these changes. All the tests passed.
Excellent.
>
Hi Team,
We have an update wrt to the PG17 AIX port.
We have reverted the changes specific to AIX (that were removed in
0b16bb8776bb8) to the latest PG17 (head).
The Buildfarm succeeded for these changes. All the tests passed.
System config
OS level : AIX-73D
> > Also would like to know some info related to the request raised for
> > buildfarm access, to register the
> > node in OSU lab. Where can I get the status of the request? Whom can I
> > contact to get the request
> > approved? So that we can add the node to the buildfarm.
> I assume you
On Wed, May 15, 2024 at 03:33:25PM +, Sriram RK wrote:
> Hi Team, we have any updated from the XLC team, the issue specific to the
> alignment is fixed
> and XLC had released it as part of 16.1.0.18. The PTF is available at the
> below location,
>
> You can also find a link here:
>
Hi Team, we have any updated from the XLC team, the issue specific to the
alignment is fixed
and XLC had released it as part of 16.1.0.18. The PTF is available at the below
location,
You can also find a link here:
https://www.ibm.com/support/pages/fix-list-xl-cc-aix.
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,
On 08.05.24 13:39, Sriram RK wrote:
We would like to understand your inputs/plans on reverting the changes
for AIX.
I think the ship has sailed for PG17. The way forward would be that you
submit a patch for new, modernized AIX support for PG18.
Hi Team, We have the AIX node ready in OSU lab, and the branches 15 and 16 got
build on the node. We had raised a request to register this node as buildfarm
member. Yet to receive the approval.
We would like to understand your inputs/plans on reverting the changes for AIX.
Thanks,
Sriram.
Hi Team, on further investigation we were able to resolve the perl issue by
setting the right PERL env location. Earlier it was pointing to the 32bit perl,
as a result the perl lib mismatch seems to be happening.
Now we have successfully built release 15 and 16 stable branches on the OSU lab
Hi Team,
There are couple of updates, firstly we got an AIX node on the OSU lab.
Please feel free to reach me, so that we can provide access to the node.
We have started working on setting up the buildfarm on that node.
Secondly, as part of the buildfarm setup on our local nodes, we are hitting
> > It would definitely make sense for a new port to start by getting
> > things going with gcc only, and then look at resurrecting xlc
> > support.
> Sriram mentioned upthread that he was looking at both of them. I'd be
> ready to assume that most of the interest is in xlc, not gcc. But I
>
On Thu, Apr 25, 2024 at 01:06:24PM +0900, Michael Paquier wrote:
> Anyway, getting an access to such compilers to be able to debug issues
> on hosts that take less than 12h to just compile the code would
> certainly help its adoption. So seeing commitment in the form of
> patches and access to
On Thu, Apr 25, 2024 at 10:16:34AM +0200, Álvaro Herrera wrote:
> On 2024-Apr-24, Bruce Momjian wrote:
>
> > I agree that targeting PG 18 for a new-er AIX port is the reasonable
> > approach. If there is huge demand, someone can create an AIX fork for
> > PG 17 using the reverted patches ---
Hi,
On 2024-04-25 00:20:05 -0400, Tom Lane wrote:
> Something I've been mulling over is whether to suggest that the
> proposed "new port" should only target building with gcc.
Yes. I also wonder if such a port should only support building with sysv
style shared library support, rather than the
Peter Eisentraut writes:
> On 25.04.24 06:20, Tom Lane wrote:
>> Something I've been mulling over is whether to suggest that the
>> proposed "new port" should only target building with gcc.
> My understanding is that the old xlc is dead and has been replaced by
> "xlclang", which is presumably
On 2024-Apr-24, Bruce Momjian wrote:
> I agree that targeting PG 18 for a new-er AIX port is the reasonable
> approach. If there is huge demand, someone can create an AIX fork for
> PG 17 using the reverted patches --- yeah, lots of pain there, but we
> have carried the AIX pain for too long
On 25.04.24 06:20, Tom Lane wrote:
Something I've been mulling over is whether to suggest that the
proposed "new port" should only target building with gcc.
On the one hand, that would (I think) remove a number of annoying
issues, and the average end user is unlikely to care which compiler
On Thu, Apr 25, 2024 at 12:20:05AM -0400, Tom Lane wrote:
> It would definitely make sense for a new port to start by getting
> things going with gcc only, and then look at resurrecting xlc
> support.
Sriram mentioned upthread that he was looking at both of them. I'd be
ready to assume that most
Michael Paquier writes:
> Some of the portability changes removed in 0b16bb877 feel indeed
> obsolete, so it may not hurt to start an analysis from scratch to see
> the minimum amount of work that would be really required with the
> latest versions of xlc, using the newest compilers as a
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).
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
On Sat Apr 20, 2024 at 10:42 AM CDT, Peter Eisentraut wrote:
3. We leave it out of PG17 and consider a new AIX port for PG18 on its
own merits.
Note that such a "new" port would probably require quite a bit of
development and research work, to clean up all the cruft that had
accumulated
Hi Team,
> I have some sympathy for this. The discussion about removing AIX
> support had a very short turnaround and happened in an unrelated thread,
> without any sort of public announcement or consultation. So this report
> of "hey, we were still using that" is timely and fair.
We
Peter Eisentraut writes:
> I have some sympathy for this. The discussion about removing AIX
> support had a very short turnaround and happened in an unrelated thread,
> without any sort of public announcement or consultation. So this report
> of "hey, we were still using that" is timely and
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
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.
On Fri, Apr 19, 2024 at 6:01 AM Andres Freund wrote:
> On 2024-04-18 11:15:43 +, Sriram RK wrote:
> > We (IBM-AIX team) looked into this issue
> >
> > https://www.postgresql.org/message-id/20240225194322...@rfd.leadboat.com
> >
> > This is related to the compiler issue. The compilers
Hi,
On 2024-04-18 11:15:43 +, Sriram RK wrote:
> We (IBM-AIX team) looked into this issue
>
> https://www.postgresql.org/message-id/20240225194322...@rfd.leadboat.com
>
> This is related to the compiler issue. The compilers xlc(13.1) and gcc(8.0)
> have issues. But we verified that this issue
> 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+
On 18 April 2024 14:15:43 GMT+03:00, Sriram RK wrote:
>Thanks Noah and Team,
>
>We (IBM-AIX team) looked into this issue
>
>https://www.postgresql.org/message-id/20240225194322...@rfd.leadboat.com
>
>This is related to the compiler issue. The compilers xlc(13.1) and gcc(8.0)
>have issues. But we
Thanks Noah and Team,
We (IBM-AIX team) looked into this issue
https://www.postgresql.org/message-id/20240225194322...@rfd.leadboat.com
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
On Fri, Apr 05, 2024 at 04:12:06PM +, Sriram RK wrote:
>
> > What you do need to do to reproduce the described problems is
> > check out the Postgres git tree and rewind to just before
> > commit 0b16bb877, where we deleted AIX support. Any attempt
> > to restore AIX support would have to
like to understand if
there are any source level changes between the ftp server and the source on
github?
Regards,
Sriram.
From: Tom Lane
Date: Friday, 29 March 2024 at 9:03 AM
To: Thomas Munro
Cc: Noah Misch , Sriram RK , Alvaro
Herrera , pgsql-hack...@postgresql.org
Subject: Re: AIX support
Th
Thomas Munro writes:
> Oh, sorry, I had missed the part where newer compilers fix the issue
> too. Old out-of-support versions of AIX running old compilers, what
> fun.
Indeed. One of the topics that needs investigation if you want to
pursue this is which AIX system and compiler versions still
On Fri, Mar 29, 2024 at 4:00 PM Thomas Munro wrote:
> On Fri, Mar 29, 2024 at 3:48 PM Noah Misch wrote:
> > The thread Alvaro and Tom cited contains an analysis. It's a compiler bug.
> > You can get past the compiler bug by upgrading your compiler; both ibm-clang
> > 17.1.1.2 and gcc 13.2.0 are
Noah Misch writes:
> On Thu, Mar 28, 2024 at 11:09:43AM +, Sriram RK wrote:
>> Also, would like to know if we can access the buildfarm(power machines) to
>> run any of the specific tests to hit this assert.
> https://portal.cfarm.net/users/new/ is the form to request access. It lists
> the
On Fri, Mar 29, 2024 at 3:48 PM Noah Misch wrote:
> On Thu, Mar 28, 2024 at 11:09:43AM +, Sriram RK wrote:
> > We are setting up the build environment and trying to build the source and
> > also trying to analyze the assert from the Aix point of view.
>
> The thread Alvaro and Tom cited
On Thu, Mar 28, 2024 at 11:09:43AM +, Sriram RK wrote:
> We are setting up the build environment and trying to build the source and
> also trying to analyze the assert from the Aix point of view.
The thread Alvaro and Tom cited contains an analysis. It's a compiler bug.
You can get past the
ards,
Sriram.
> From: Sriram RK
> Date: Thursday, 21 March 2024 at 10:05 PM
> To: Tom Lane t...@sss.pgh.pa.us<mailto:t...@sss.pgh.pa.us>, Alvaro Herrera
> Cc: pgsql-hack...@postgresql.org<mailto:pgsql-hack...@postgresql.org>
> Subject: Re: AIX support
> Th
Thanks, Tom and Alvaro, for the info.
We shall look into to details and get back.
From: Tom Lane
Date: Thursday, 21 March 2024 at 7:27 PM
To: Sriram RK
Cc: pgsql-hack...@postgresql.org
Subject: Re: AIX support
Sriram RK writes:
> We are working on AIX systems and noticed that the thr
Sriram RK writes:
> We are working on AIX systems and noticed that the thread on removing AIX
> support in Postgres going forward.
> https://github.com/postgres/postgres/commit/0b16bb8776bb834eb1ef8204ca95dd7667ab948b
> We would be glad to understand any outstanding issues hindering the
>
On 2024-Mar-21, Sriram RK wrote:
> Hello Team,
>
> We are working on AIX systems and noticed that the thread on removing AIX
> support in Postgres going forward.
>
> https://github.com/postgres/postgres/commit/0b16bb8776bb834eb1ef8204ca95dd7667ab948b”
>
> We would be glad to understand any
On Tue, Jul 12, 2022 at 10:30 AM Tom Lane wrote:
> Thomas Munro writes:
> > Here's a patch to remove all of these.
>
> Looks sane by eyeball --- I didn't grep for other references, though.
Thanks, pushed.
> > I didn't originally suggest that because of some kind of (mostly
> > vicarious)
Thomas Munro writes:
> Here's a patch to remove all of these.
Looks sane by eyeball --- I didn't grep for other references, though.
> I didn't originally suggest that because of some kind of (mostly
> vicarious) nostalgia. I wonder if we should allow ourselves a
> paragraph where we remember
On Tue, Jul 12, 2022 at 7:24 AM Tom Lane wrote:
> Thomas Munro writes:
> > It's funny to think that you probably could run modern PostgreSQL on
> > the Sun 3 boxes the project started on in 1986 (based on clues from
> > the papers in our history section) if you put NetBSD on them, but
> > you'd
Thomas Munro writes:
> On Mon, Jul 11, 2022 at 6:49 PM Tom Lane wrote:
>> SuperH might be twitching a bit less feebly than these three,
>> but it seems to be a legacy architecture as well. Not much
>> has happened there since the early 2000's AFAICS.
> It looks like there's an sh3el package
Robert Haas writes:
> On Mon, Jul 11, 2022 at 2:49 AM Tom Lane wrote:
>> I think it'd be pretty reasonable to disclaim support for
>> any architecture that doesn't have a representative in our
>> buildfarm, which would lead to dropping all four of these.
>> If you don't like it, step up and run
On Mon, Jul 11, 2022 at 2:49 AM Tom Lane wrote:
> While we're here ...
>
> + Code support exists for M68K, M88K, M32R, and SuperH, but these
> architectures are not known to have been tested recently.
>
> I think it'd be pretty reasonable to disclaim support for
> any architecture that
On Mon, Jul 11, 2022 at 6:49 PM Tom Lane wrote:
> SuperH might be twitching a bit less feebly than these three,
> but it seems to be a legacy architecture as well. Not much
> has happened there since the early 2000's AFAICS.
It looks like there's an sh3el package for PostgreSQL on NetBSD here,
Thomas Munro writes:
> Yeah. I wasn't too sure if that was mostly about "recent" or mostly
> about "all distributions" but it wasn't doing much. Thanks, pushed.
While we're here ...
+ Code support exists for M68K, M88K, M32R, and SuperH, but these
architectures are not known to have
On Mon, Jul 11, 2022 at 11:38 AM Tom Lane wrote:
> WFM. I also wonder if in
>
> + PostgreSQL can be expected to work on current
> + versions of these operating systems: Linux (all recent distributions),
> Windows,
> + FreeBSD, OpenBSD, NetBSD, DragonFlyBSD, macOS, AIX, Solaris, and
Thomas Munro writes:
> OK, I word-smothe thusly:
> + and PA-RISC, including
> + big-endian, little-endian, 32-bit, and 64-bit variants where applicable.
WFM. I also wonder if in
+ PostgreSQL can be expected to work on current
+ versions of these operating systems: Linux (all recent
On Fri, Jul 8, 2022 at 4:24 PM Tom Lane wrote:
> Thomas Munro writes:
> > * The documented list mentions some in different endiannesses and word
> > sizes explicitly but not others; I think it'd be tidier to list the
> > main architecture names and then tack on a "big and little endian, 32
> >
On Tue, Jul 5, 2022 at 1:32 AM Andres Freund wrote:
> I just thought an easier way - why don't we introduce a 'catalog_double'
> that's defined to be pg_attribute_aligned(whatever-we-need) on AIX? Then we
> can get rid of the manually enforced alignedness and we don't need to contort
> catalog
On Thu, 7 Jul 2022 at 22:36, Thomas Munro wrote:
>
> * Since Greg Stark's magnificent Vax talk[1], we became even more
> dependent on IEEE 754 via the Ryu algorithm. AFAICT, unless someone
> produces a software IEEE math implementation for GCC/VAX... if I had
> a pick one to bump off that list,
Thomas Munro writes:
> * The documented list mentions some in different endiannesses and word
> sizes explicitly but not others; I think it'd be tidier to list the
> main architecture names and then tack on a "big and little endian, 32
> and 64 bit" sentence.
As phrased, this seems to be saying
On Thu, Jul 7, 2022 at 1:02 AM Peter Eisentraut
wrote:
> On 06.07.22 04:21, Thomas Munro wrote:
> > /*
> >* Do not try to collapse these into one "w+" mode file. Doesn't work
> > on
> > - * some platforms (eg, HPUX 10.20).
> > + * some platforms.
> >*/
> >
On Wed, Jul 6, 2022 at 12:27 PM Andres Freund wrote:
> I think my proposal of introducing a version of double that is marked to be 8
> byte aligned should do the trick as well, and doesn't have the problem of
> changing the meaning of 'double' references in external headers. In fact, we
> already
Hi,
On 2022-07-06 11:55:57 -0400, Robert Haas wrote:
> On Sat, Jul 2, 2022 at 2:34 PM Andres Freund wrote:
> > I strikes me as a remarkably bad idea to manually try to maintain the
> > correct
> > alignment. Even with the tests added it's still quite manual and requires
> > contorted struct
On Sat, Jul 2, 2022 at 2:34 PM Andres Freund wrote:
> I strikes me as a remarkably bad idea to manually try to maintain the correct
> alignment. Even with the tests added it's still quite manual and requires
> contorted struct layouts (see e.g. [1]).
>
> I think we should either teach our system
I wrote:
> Our HEAD does work on that NetBSD installation. I can try this
> patch, but it'll take an hour or two to get results ... stay tuned.
Indeed, I still get a clean build and "make check" passes with
this patch.
regards, tom lane
Peter Eisentraut writes:
> On 06.07.22 04:21, Thomas Munro wrote:
>> /*
>> * Do not try to collapse these into one "w+" mode file. Doesn't work on
>> - * some platforms (eg, HPUX 10.20).
>> + * some platforms.
>> */
>> termin = fopen("/dev/tty", "r");
>> termout = fopen("/dev/tty", "w");
On 06.07.22 04:21, Thomas Munro wrote:
/*
* Do not try to collapse these into one "w+" mode file. Doesn't work on
-* some platforms (eg, HPUX 10.20).
+* some platforms.
*/
termin = fopen("/dev/tty", "r");
termout = fopen("/dev/tty", "w");
On 2022-07-06 01:33:58 -0400, Tom Lane wrote:
> Andres Freund writes:
> > There's also a bunch of #ifdef __ia64__ in
> > src/backend/utils/misc/guc-file.c,
> > contrib/seg/segscan.c and contrib/cube/cubescan.c
>
> And all our other flex output files --- AFAICS that's part of flex's
> recipe and
Andres Freund writes:
> There's also a bunch of #ifdef __ia64__ in src/backend/utils/misc/guc-file.c,
> contrib/seg/segscan.c and contrib/cube/cubescan.c
And all our other flex output files --- AFAICS that's part of flex's
recipe and not under our control.
regards, tom
Hi,
0001 looks good to me.
There's a leftover itanium reference in a comment in
src/include/port/atomics/generic-msvc.h
There's also a bunch of #ifdef __ia64__ in src/backend/utils/misc/guc-file.c,
contrib/seg/segscan.c and contrib/cube/cubescan.c
Otherwise lgtm as well.
Greetings,
Andres
On Wed, Jul 6, 2022 at 3:26 PM Andres Freund wrote:
> On 2022-07-06 14:21:50 +1200, Thomas Munro wrote:
> > - * Notice that this means that we actually clear the word to set
> > - * the lock and set the word to clear the lock. This is the
> > - * opposite behavior from the SPARC
Thomas Munro writes:
> OK, here's a new attempt, this time leaving the hppa bits in. The
> main tricksy bit is where s_lock.h is simplified a bit by moving the
> fully inline GCC-only hppa support up a bit (it was handled a bit
> weirdly with some #undef jiggery-pokery before to share stuff
Hi,
On 2022-07-06 14:21:50 +1200, Thomas Munro wrote:
> --- a/src/backend/port/hpux/tas.c.template
> +++ /dev/null
> @@ -1,40 +0,0 @@
> -/*
> - * tas() for HPPA.
> - *
> - * To generate tas.s using this template:
> - * 1. cc +O2 -S -c tas.c
> - * 2. edit tas.s:
> - * - replace the
On Tue, Jul 5, 2022 at 4:53 PM Tom Lane wrote:
> Thomas Munro writes:
> > On Mon, Jul 4, 2022 at 12:08 PM Tom Lane wrote:
> >> I would not stand in the way of dropping HP-UX and IA64 support as of
> >> v16. (I do still feel that HPPA is of interest, to keep us honest
> >> about spinlock
Hi,
On 2022-07-05 08:13:21 +0200, Peter Eisentraut wrote:
> On 05.07.22 07:31, Andres Freund wrote:
> > On 2022-07-02 11:33:54 -0700, Andres Freund wrote:
> > > If we decide we want to continue supporting AIX we should bite the bullet
> > > and
> > > add a 64bit-int TYPALIGN_*. It might be worth
Hi,
On 2022-07-05 01:36:24 -0400, Tom Lane wrote:
> Andres Freund writes:
> > I just thought an easier way - why don't we introduce a 'catalog_double'
> > that's defined to be pg_attribute_aligned(whatever-we-need) on AIX? Then we
> > can get rid of the manually enforced alignedness and we don't
On 05.07.22 07:31, Andres Freund wrote:
On 2022-07-02 11:33:54 -0700, Andres Freund wrote:
If we decide we want to continue supporting AIX we should bite the bullet and
add a 64bit-int TYPALIGN_*. It might be worth to translate that to bytes when
building tupledescs, so we don't need more
Andres Freund writes:
> I just thought an easier way - why don't we introduce a 'catalog_double'
> that's defined to be pg_attribute_aligned(whatever-we-need) on AIX? Then we
> can get rid of the manually enforced alignedness and we don't need to contort
> catalog order.
Hm, do all the AIX
Hi,
On 2022-07-02 11:33:54 -0700, Andres Freund wrote:
> If we decide we want to continue supporting AIX we should bite the bullet and
> add a 64bit-int TYPALIGN_*. It might be worth to translate that to bytes when
> building tupledescs, so we don't need more branches (reducing them compared to
>
Thomas Munro writes:
> On Mon, Jul 4, 2022 at 12:08 PM Tom Lane wrote:
>> I would not stand in the way of dropping HP-UX and IA64 support as of
>> v16. (I do still feel that HPPA is of interest, to keep us honest
>> about spinlock support --- but that dual-stack arrangement that IA64
>> uses is
On Mon, Jul 4, 2022 at 12:08 PM Tom Lane wrote:
> I would not stand in the way of dropping HP-UX and IA64 support as of
> v16. (I do still feel that HPPA is of interest, to keep us honest
> about spinlock support --- but that dual-stack arrangement that IA64
> uses is surely not part of anyone's
Andres Freund writes:
> On 2022-07-03 20:08:19 -0400, Tom Lane wrote:
>> I do still feel that HPPA is of interest, to keep us honest
>> about spinlock support
> I.e. forgetting to initialize them? Or the weird alignment stuff it has?
The nonzero initialization mainly, and to a lesser extent the
Hi,
On 2022-07-03 20:08:19 -0400, Tom Lane wrote:
> I would have preferred to keep pademelon, with its pre-C99 compiler, going
> until v11 is EOL, but that ain't happening.
I'm not too worried about that - clang with
-std=c89 -Wc99-extensions -Werror=c99-extensions
as it's running on mylodon
Hi,
On 2022-07-04 10:33:37 +1200, Thomas Munro wrote:
> I don't have a dog in this race, but AIX is clearly not in the same
> category as HP-UX (and maybe Solaris is somewhere in between).
The reason to consider whether it's worth supporting AIX is that it's library
model is very different from
Thomas Munro writes:
> On Sun, Jul 3, 2022 at 8:34 AM Tom Lane wrote:
>> I am a little concerned though that we don't have access to the latest
>> version of AIX --- that seems like a non-maintainable situation.
> The release history doesn't look t bad on that front: the live
> versions are
On Sun, Jul 3, 2022 at 8:34 AM Tom Lane wrote:
> I am a little concerned though that we don't have access to the latest
> version of AIX --- that seems like a non-maintainable situation.
The release history doesn't look t bad on that front: the live
versions are 7.1 (2010-2023), 7.2
Andres Freund writes:
> What made me look at this issue right now is that the alignment issue lead the
> 56bit relfilenode patch to move the relfilenode field to the start of pg_class
> (ahead of the oid),
Agreed, up with that we should not put. However ...
> because a 64bit value cannot be
Hi,
On 2022-07-02 16:34:35 -0400, Tom Lane wrote:
> Agreed. But I think that this sort of thing is better driven by
> "when there's no longer anyone willing to do the legwork" than
> by project policy. IOW, we'll stop when Noah gets tired of doing
> it (and no one steps up to take his place).
Peter Geoghegan writes:
> Maybe it is still worth hanging on to AIX support for the time being,
> but it would be nice to have some idea of where we *will* finally draw
> the line. If the complaints from Andres aren't a good enough reason
> now, then what other hypothetical reasons might be good
On Sat, Jul 2, 2022 at 12:22 PM Tom Lane wrote:
> Now, it's certainly possible that AIX is the only surviving platform
> that hasn't adopted bug-compatible-with-glibc interpretations of
> POSIX. But I think the standard is the standard, and we ought to
> stay within it. So I find value in these
Hi,
On 2022-07-02 11:54:16 -0700, Peter Geoghegan wrote:
> I tend to agree about dropping AIX. But I wonder if there is an
> argument against that proposal that doesn't rely on AIX being relevant
> to at least one user. Has supporting AIX ever led to the discovery of
> a bug that didn't just
Peter Geoghegan writes:
> I tend to agree about dropping AIX. But I wonder if there is an
> argument against that proposal that doesn't rely on AIX being relevant
> to at least one user. Has supporting AIX ever led to the discovery of
> a bug that didn't just affect AIX?
Searching the commit log
1 - 100 of 101 matches
Mail list logo
