Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vl41V-006TJy-0K for pgsql-hackers@arkaria.postgresql.org; Wed, 28 Jan 2026 11:47:50 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vl41U-0018UX-0p for pgsql-hackers@arkaria.postgresql.org; Wed, 28 Jan 2026 11:47:48 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vl2k9-000kan-2L for pgsql-hackers@lists.postgresql.org; Wed, 28 Jan 2026 10:25:50 +0000 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]) by makus.postgresql.org with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vl2k6-002iaI-0M for pgsql-hackers@lists.postgresql.org; Wed, 28 Jan 2026 10:25:48 +0000 Received: from pps.filterd (m0356516.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 60RJlAxg028699 for ; Wed, 28 Jan 2026 10:25:46 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=cc :content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to; s=pp1; bh=tfv/McQY+LAOSo0wBvdHv97la3+6CD HOIeaNPsEEG+0=; b=BG/lRmEkhYBESj6ySkhI+DY/dKhzmWzU0zrqfmKkEahRRr bG3F+vTLLoTS2q9SApZ9Y+5iQJ6Xa0X59qe/AADBCO1zMwfV7kwC/2tgw2Eop7m9 KncHQP9mE4mcNdm7tDteq6oFQDx+H34Z3XlYkoMQjAu3APLIMxbiI26V+tUiusgu 7ThNzIp5Ne4HgbXS/Nob7YDQDEiTb3o8HQB/VH5/SWbKXijBtwAItzL+8/CVymFv xoLInpk1ysXSYeem+M70ULGs7pc99KV7Y/ogU8hkCaiB5yfEZkZEIxhkoBIda676 nY1M+cJJ86JFEU7XqZtCzDb8Y4kil2Nnpbp8XE0w== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 4bvkgmrr1h-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 28 Jan 2026 10:25:46 +0000 (GMT) Received: from m0356516.ppops.net (m0356516.ppops.net [127.0.0.1]) by pps.reinject (8.18.1.12/8.18.0.8) with ESMTP id 60SAApor030038 for ; Wed, 28 Jan 2026 10:25:45 GMT Received: from bn1pr04cu002.outbound.protection.outlook.com (mail-eastus2azon11010042.outbound.protection.outlook.com [52.101.56.42]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 4bvkgmrr1d-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 28 Jan 2026 10:25:45 +0000 (GMT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=CCzUK1XosLBiOopJvYHFdz3T+j/VeVX1xCMsDTN7rYEhXWHGa2klZZOTHjGDSaFED0fRJzIDrd7POy7AbVvl0t5tSXGEqW3bxw6NqtAfvMQJ5WPbb6y8wXlqXFRbs8AGiGKtkngG0p4FkbORCL16QrPnbsKJgeZXiFOjjlRbPzDtKhOqwlXQVgbXfA7PAx/F/wlqlcvx2bV/vrMz11lWIX940zFP3dXFb+LbA7mPz/mJUjFXg6m2L+o+QaKqi24ppbLKCZ05prdfFS/akPEmMgQl6L7tVasa8Xoi9hLO9UlnZy5XvsDJ5Qj1XpkS/rGDrPIuXbUPl/jNJHoe4v5ODw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=a0U2B8Sp/LWRaaDoY9Xpy8uqdOmBcPtM2Eyz5ZH9V88=; b=yBVIRlN0bwIeW2XUIDsC+pIGqhwsWPBDFjoydcJSSoN3R2dJXWWe1nTVCErWJw/P5sDPnpAxZHlXB/z2CI3ygiCePJVoE+IU+5Uk5WM9dUpOiBkggFzUgMGN4DfY/6/Z+EpFhD2G1u4vjA+ibz/pRM7v0fUvqLL+sq+ow+6Qy2q5/HjNnrkAQC80Db1WiKq9UrXiZFfzEfa7s2CCq5EiA1HOl4I+rTzJcCsyXABdYWwhFjw5kEWj+wHt6mibntH95izbc1qs9vBGM02KgRFy9hWrYsE5+jGxvAVNSfoT55FDhFXdfZ14v99yKeDUk2FvetaHllNiKwbJbkJm79QdeQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ibm.com; dmarc=pass action=none header.from=ibm.com; dkim=pass header.d=ibm.com; arc=none Received: from LV8PR15MB6488.namprd15.prod.outlook.com (2603:10b6:408:1f4::13) by SN7PR15MB5707.namprd15.prod.outlook.com (2603:10b6:806:34f::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9564.7; Wed, 28 Jan 2026 10:25:41 +0000 Received: from LV8PR15MB6488.namprd15.prod.outlook.com ([fe80::2520:f26a:6eb:6c6d]) by LV8PR15MB6488.namprd15.prod.outlook.com ([fe80::2520:f26a:6eb:6c6d%5]) with mapi id 15.20.9564.006; Wed, 28 Jan 2026 10:25:41 +0000 From: Aditya Kamath To: Srirama Kucherlapati , "peter@eisentraut.org" , "andres@anarazel.de" CC: "pgsql-hackers@lists.postgresql.org" , "hlinnaka@iki.fi" , "tristan@partin.io" , "postgres-ibm-aix@wwpdl.vnet.ibm.com" Thread-Topic: [EXTERNAL] Re: AIX support Thread-Index: AQHae4rr5/ageaPz8EuxaB+VNKiBu7FCOGKAgAArgSaACn9l2IABLM4AgAADTgCAAAP8gIAABU6AgAvJNWiAAB/ogIATySEqgACu3ACAARripYAB4tSAgAAMOICABwWYgIAAB3wAgAAD0oCAAAcGgIACYnHWgAxC+/6AAz5ikoAC7ZKggAAzhgCAAAZWgIALF3TtgAAGbYCAAAc8toABabZigAAKZACACX4wBIAA83CAgAA8Eh6AAGyZAIAD7Q2AgBOpYxWABEWoAIABtJbFgAm10OGAAxsEAIAACpc/gAM2cX+AU/nKsoAASmYAgAB8EsuAAFNfAIArcUjPgACuTICAAndU4oAGmUOsgAqpmr2AACCfgIAA83KngA6qCqSAUfOrvIAAY2wAgAOXbQuACcNL24Ad9dXhgAMilgCARWvRCIAr97MUgAAoXgCAD7/Y/YAaKmSAgAAT1RqAAEbmgIABx94wgAA+JACAAUalI4ACvbeAgAgVLqSABM5vSIDdmu/GgBq8ygCAAt6PgIAAFZEAgAGzmQCAAAL5gIAABq1TgCKRccWAJD/ugIAEv++AgC2FMwmAAFPTgIANzJJMgAQ4YwCABSbc9IAN/GYogBFSY1mAAiAlgIAAgWpFgAoFtoCAACdJOoADCirwgATBDACAAmHH7YAAYE4i Date: Wed, 28 Jan 2026 10:25:41 +0000 Message-ID: References: <61d9ecc8-da4e-487a-9774-838b044cda4d@eisentraut.org> In-Reply-To: Accept-Language: en-IN, en-US Content-Language: en-IN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-reactions: allow x-ms-publictraffictype: Email x-ms-traffictypediagnostic: LV8PR15MB6488:EE_|SN7PR15MB5707:EE_ x-ms-office365-filtering-correlation-id: ec6268fb-4000-4578-37f6-08de5e57965b x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|366016|376014|38070700021|13003099007|8096899003; x-microsoft-antispam-message-info: =?utf-8?B?Qnk4dUNXYmszQXNiNmd1aUdma21WK0M4UUJsUG9CR0VQQVYzYVdNRzNYc0t3?= =?utf-8?B?SzBHa0ZaU05PRmwra1FZNDRYMnp1M2Z6V2JEejVlYitScldvRk1MWWI2N092?= =?utf-8?B?TmRIQy9zNVJUU04wRE9IYnZEaXJmT29DUEtpUmIrUHkxYmpKc1JJYVpJSExN?= =?utf-8?B?WXRTOUV3M3RsOUZBUjdjaUxpMElFeGZKazkrTm9qTUFBQnBuYUF0S3ZHZHhW?= =?utf-8?B?MTlRRmFUdG81Z04wL1FTV1BOWGkwM3F4MmRJVHRyR245bmJ5bTA4eFc0TWtT?= =?utf-8?B?SG90cWt4U1RodVI3bHNPQlk5b2sydmFjTmFzQmtHaVkrazgvelEwbjMxbUlD?= =?utf-8?B?V3NnUldvb0lieVFXMWNpUm04M2xaZHpYa3JYRmxiallNV0VmUVQydXk5NlUx?= =?utf-8?B?NnV0bGNFZk0wc013R0hiK3BtanZEaDl3d0pZK3VOejZVNEdPMzYxdkZGbnFo?= =?utf-8?B?anVZbUFoKzdWbmJSUmZVa1JjZElObEczQk1PODFkSzBXdm01c2h2c0JKYkJJ?= =?utf-8?B?VmcraVluYkVUOFUzaENjRUtyUVNkQVFwcFpjcFVJNUJJOGt4dzQxSzJWb2R3?= =?utf-8?B?QmV4ZXdscDdGNnp4MzFPWnFNa3hnQjF5NmFVbkNiRFNpd2ZDN04yZFRvMnFT?= =?utf-8?B?aSt2c1QyV082WUpuQy9MSStkd2NaSzNvcnFKVW9NcHR1UUtxelVmRndZcDlx?= =?utf-8?B?R3FFNUdiVjBOV0xvY1l4ZXEwRXdXaHdRUVduUzJSVjJpWE5WaXVqdnVBWW1o?= =?utf-8?B?cm44WEpsTjVSSzEzcTA5VzNNU0FXemJISlN1MFNBWjBiYXM0MmN5L3I4TWFC?= =?utf-8?B?QXdncElmYTFpTVQxQVpQWGR3MmxMa0NmNDlvYXRwYzRyWlBNN2p3c2ZqQkVM?= =?utf-8?B?RHpENmtzZFhyeG4yODJja1pDbXdDaHczUkVnKzNKZDZ5ZFBqSi9ndFJCZ3B5?= =?utf-8?B?NEJZWXlsNWUxNXNLSGYydTdhRjlqZTlEb2lHZUJtbWxkR0dIUFljTGFnOHBN?= =?utf-8?B?VHFSOE4xY1hZRG9qcFo5dGRtVWhpdXQ0UUpBTks3emw3eWpsNFJQT2w3UlQw?= =?utf-8?B?YjFKdjNVYTVsWGl4aTZEWVByM09oSW1BSkJYejEvUU5ReHpvWFJsalZvdU16?= =?utf-8?B?eTFEU0NBbFVXQ0VVYUhiNmg0eW5sWjk1UE9aUllIRU9mRUJmWUROemJHSDg5?= =?utf-8?B?SU9OOGJQZHgvYWZkNlJsUHdxZWl6Q3lwdkZYdjVQL1NPNTNTS0U3eFpWNHlJ?= =?utf-8?B?c1l3ZkZXNWxNeFNUb293Rm9jZ2NvVjhDMXQvS2xyUkNneVhsdkpNWEdqblVR?= =?utf-8?B?bk93dDNrV2g3WC9leXFuWEhEWjA4Y0g0Sk5qc0FQc0NFbko2TEZLU2tMdzNq?= =?utf-8?B?R3pqVWtjYnl6d0tpam50QUxPVlVuQW1PZzV1NTZOa3g1WHJTTDBSbTFqcEs3?= =?utf-8?B?Z01RYnR5dEtiK0dLR1ZyemlMTlg0RWM5eUpDZXgrSVYzU3Myb00wQnM5TXAv?= =?utf-8?B?T3g3YUVNVnM4UU9YTTVzSEZHQ1VXOTRYNWl6NGgzaFBlUE56VUpqL3grWjBD?= =?utf-8?B?MFNtQnk5bUdDSmJ3cHRoekx3TGhENUY2Mis5eFdYQk9mVDFqUGdWcThGaWFp?= =?utf-8?B?NjRTaXRtaG11cDJ2UTRyTmdKZkdBRUZMVmdrdTNOZGNqRDYzMUkyS3Ftck1D?= =?utf-8?B?R3Z1d241MlBOUFlGRE00emdGckE2RGRuUldHUWFxSk1Eazl5TTBDeUk1bmFi?= =?utf-8?B?YWltYVc5RWw1cHhKRDVUNDRiMTZIY0w0eFRWclJSdDVFRDFiR2tvNGk0a2tO?= =?utf-8?B?akNOeksxRVJWdnV3ZjlqYytvcFNmRXlLWDc2WEdTOXZodUcrMVQ3ckNRMzZr?= =?utf-8?B?VVd5dmdqQ3RQUFFtVnhrYUJMa2NaZ3BQTFRsMEdsamJud2RMc2E1aHhiTlZY?= =?utf-8?B?N0NnQ0hPejR5MUpwV1cwTjYzby90TXpzc2w5WDN4bG5peVVNbVVIMGxGdDdo?= =?utf-8?B?cXczdGdVc3NQYkMxZHNxcnR0bllDYXpLUG1yUEVWYXk2amo2YjNMQldzNGVW?= =?utf-8?B?aVFXY3NvYVdIVXdpUVh2NStMb09kLzFwMUZFdWs4SE9xQXM3N2E5bTRCUnRj?= =?utf-8?Q?s4EtuYKfA/R4CGzACwPjiR05I?= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:LV8PR15MB6488.namprd15.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(376014)(38070700021)(13003099007)(8096899003);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?QU96WWZveE01eXk3QXErU1RHQ2UxWFNDNlZOVjVaVURNVDJETzJac1FnbTNS?= =?utf-8?B?Yyt4akRyUWk3dVpqTmYyV2lyeWh5NUJYN0lBWXJOd0toNHViZGhHaDhwaXhV?= =?utf-8?B?cDByZmREYUNwREJkSHBqdHlVS1Z2QllrTzBSV05wem5pTjRJbEsxUHJLZnNM?= =?utf-8?B?eDhPQ01PdlQ1cjZPZ0htUkFhMjNVd1hkaWhVcXJkTW9keitPQVo1VXIyUFBr?= =?utf-8?B?R3pvVG9vK211bXdIbDl5QThwdDlmWU9KQjVnQmxiMi9VRExJQUJ0eFRtV0E5?= =?utf-8?B?Z3RUclgvcDBmazZwU2ZDMXUyc015ZnUvYTFzZ254aTBoYTFBaHZpWTlBSnh5?= =?utf-8?B?aEVBTXJYY2JDdzNrQlVZK29zblIvL0RZSG1QaGxNM0RyVlJIci9GUVJrVVJu?= =?utf-8?B?Vi8vYitZTW9yTW5tTVBOZXJYcVhWZGM4OU9OUHFXSml3akpFNFdRbDg0QWpy?= =?utf-8?B?aGtWTGVuOGVkT3ZDNjhLd0VMWjI3T004UndWb3owTU52a2Z2ZnBjK09ackE5?= =?utf-8?B?R3dYUFBRb3hWam1DNHA0WTZnQmtPcXpiU25kNk1UeHZQSHZmb1lvdVJwZ001?= =?utf-8?B?Q2NEYkNKU0czSDYyWWFRVkN1Wk1hb3RLS05SZjBnWW9tc1lnZUl5OWdvN3BP?= =?utf-8?B?azVJVFRmK1ptSGM5R3Q5bEsyREloUlg2MzV2VTJyZnk2blNqT2VsRis5R0lR?= =?utf-8?B?dTFGSm92eDdIbVIvcUpXbzlHWXBlQnVTSno1cVlBNDJ3WmxJelpGRzg2NTha?= =?utf-8?B?TlUyNDloL2FucElZT0lZMXZWWHkydnk2am53aEtJaVArbFVTeFlRUzN1NUpn?= =?utf-8?B?SUQrU2hOM3k0NjBlNEdqZHVhTEwxU3F1enlKTGV2L3N3aFFQLyt1T2dMT3ky?= =?utf-8?B?TTZteCt2NXl1eGtVbnNjcmErc2Z5RWpqQnU4YTNEdkdESWk4U24zYndkdkRD?= =?utf-8?B?OVZtNk9xRTAvYnlCcnpxQmJCOUxaSE1ZWU44blB3aElFQXpDTmhjWWMzalk2?= =?utf-8?B?SExhRUduYWh2dVVnS2F3VytVUEovSVhTTFczQUorLzNJSFRMdWQxMmhkaUJR?= =?utf-8?B?RVZoZk1BL3dOZ2RZOEc1cklnRUN0Y2hIY1oxZnI0d3FTM2dlcG90Q29XMGV3?= =?utf-8?B?K0NJQnBIVlhpdnN6WmRBWEpadHUwcEZYMHMwajZHNzF5aGp6b1Q0Z3Avd2pw?= =?utf-8?B?VmhFSWlhWGUxd0orYStqNlF3b29qWUNob2J4MVpybEYvck11Q1o1SE9abS85?= =?utf-8?B?ZFhIYkF6M0lqTUNyRUN2ZU5LUDVBdGQ2MjdTazJQU1cyQkk0QjBzQ2p0S1pn?= =?utf-8?B?RVJpLzY1MmhHdi9vMWJXQlRmd3pITnhGZ0wzSFdzcDg2WUZGaGV1NlNvVDl0?= =?utf-8?B?Qk1aT3VyYWxEZGxWRTBNcGV4dXdxN0JEZUNoR2k5YUxObjZzR2xmazJmTDJI?= =?utf-8?B?TGVIWWE3NWN5MVBKeGkxWDZmZ2hFR1d0NnQ4Z2k2b2UxMGlBbHcvZ1lGMDhk?= =?utf-8?B?QU5LRHE0clA0SzJ6RVJZRWI5Y3RIWkpnRlVqUjlVY0dEVkdYUTJTM3czT0hi?= =?utf-8?B?OHA1RmNWU294aXA2Sk85bTh5OFc1SnRrNHJXTk1ndWFsOVcwcnNHZXNwQnkv?= =?utf-8?B?RXphZUdtV1IyZWVyMFkxQ2cxOFphbjd2dW8xSmhtemphZ0t6b2o3RXI2eFls?= =?utf-8?B?Z0htREgzSzdLaWRXT2xVbW41TnhqcjhPQ09LQWJDcllTSUZIZTYzY0h6MXFH?= =?utf-8?B?WGRIRnhjdDE4dlpaVDU2bG4vVHRvdE9yaEo0WHNMNU11Y25MTTcvM3JRcHZq?= =?utf-8?B?VzhuM1VjeGZHb21UMHpjV3M4Zmt6SnhjY0FobGhubkkwbjI3d0llZklhT01S?= =?utf-8?B?amJjRlVzakY1LytXWVJHbkQwMDN5ZjQrOG5WMW92bFhaOEZwZzZUeXFXR0sx?= =?utf-8?B?V1dzVE50VmVVOWNTWHp3dW5iYmtqLzFBbytwSU9NUUgwSjdVRVNHZ2tCdk5y?= =?utf-8?B?eDNyMDlWY1BFN2NoaDVBSHNKajZsOGQvMzZhMUpiRDlueW9xcUxmem0wb3Bt?= =?utf-8?B?NDd6aTloU3FvenBMOW1KKzJkczM0ZGNTY1ZNVGxwY3NERnZwSmpTK3hkdVYr?= =?utf-8?B?VUswYjRrL1p2VUZLeUJQZDZMRllTa3RBWHJjWFRLZklobUZHcnB4c0RYRzhM?= =?utf-8?B?N3lERjBMd0JySlpIUHgxTXhBTFpiaGtXekhvSDdadFdKVjNkL2pyUmFBeFI2?= =?utf-8?B?OUZIdFA5ckhocG8yQWRyODFFTmtyYU1QcXgxOGVZL2dWZzh0VFdPaUxJRlov?= =?utf-8?B?ajZ2R2Y0OUNYMDhDeXdJS1gxRUNJTHk3SlJ4dk5wTEl1emh3Q05KRzdmV1ps?= =?utf-8?Q?0NwinSFknV0b5X/w=3D?= Content-Type: multipart/alternative; boundary="_000_LV8PR15MB64883FC333B351ABD169E874D691ALV8PR15MB6488namp_" X-OriginatorOrg: ibm.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: LV8PR15MB6488.namprd15.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: ec6268fb-4000-4578-37f6-08de5e57965b X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Jan 2026 10:25:41.0892 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: fcf67057-50c9-4ad4-98f3-ffca64add9e9 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: VZFZna5ycajW9pCcJG4HNXPbnqG7ZRLAQCeZ+y1RVRnZdn8A0usGUmg9mRLk4645dbtQVoqXYS2nm5cXbpCgGQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN7PR15MB5707 X-Proofpoint-GUID: yEM9L6NXY6aqZdPT7jee3MYzOWuy1Bqf X-Authority-Analysis: v=2.4 cv=Gr1PO01C c=1 sm=1 tr=0 ts=6979e429 cx=c_pps a=cLTib2BoJD1e+Gs0wkBYAA==:117 a=z/mQ4Ysz8XfWz/Q5cLBRGdckG28=:19 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19 a=xqWC_Br6kY4A:10 a=vUbySO9Y5rIA:10 a=VkNPw1HP01LnGYTKEx00:22 a=ukH1R-b_AAAA:8 a=mDV3o1hIAAAA:8 a=VnNF1IyMAAAA:8 a=YaAL5w1MAAAA:8 a=epTmVMiNAAAA:8 a=f8YNDW9AvKkZGquDyE8A:9 a=QEXdDO2ut3YA:10 a=ZP04JxRPGQ4A:10 a=fcnMFW99P4TMiFcP:21 a=_W_S_7VecoQA:10 a=zUGFzhdS3I8ccRoxxLmr:22 a=93iBSmLbQUaEir46gWPx:22 X-Proofpoint-ORIG-GUID: yEM9L6NXY6aqZdPT7jee3MYzOWuy1Bqf X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwMTI4MDA4NCBTYWx0ZWRfX4Y4sqNOu7R1W ZRh99TKB9kxKxNgYI2tBWrqaXPyAzcdrS56Yb1OElkS5IC0yOfUqhr2HFjspknjIYTkG293OeNI runwcmEh0bXD39rqQVODkuXRKR3BnWqg1vucBoKwc9haUYS2sUcLkNsxWf6rUYDFeyhyJWL19fF wgswcJBBJRAXvdtp2B0WnG16X8G1ImV9IT4wdUnn07eyJ3s8Lt7YqgtnasyCFhaIx5w1cQ7iWLr J6q2PiOxE7Hem5Z9yqas7L0QFD/QnKiAHh6TRMi7hD5lVByn5IAMVPFkqRpdJQZAhO5COO1dlO9 spInwwpyShTjrl/rhauKwmCxT3cpgwdytLkVPGfr+Al3H8GJKHKZ4RXx8QkiCJcVl9wP+GcdyK8 k1z5iaWuUyDbK9jtRb7LaAY+SGVzluaLH7f61BwsPaaOGQXWXoCeVJxu9KpnZRDV3epx04u+dju Hu1EK+ZnJ4jXcxjHe6g== MIME-Version: 1.0 Subject: RE: AIX support X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1121,Hydra:6.1.51,FMLib:17.12.100.49 definitions=2026-01-28_02,2026-01-27_03,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 clxscore=1011 lowpriorityscore=0 suspectscore=0 impostorscore=0 phishscore=0 malwarescore=0 adultscore=0 bulkscore=0 spamscore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=2 engine=8.19.0-2601150000 definitions=main-2601280084 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --_000_LV8PR15MB64883FC333B351ABD169E874D691ALV8PR15MB6488namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Andrew, Thank you for your review comments for AIX so far. While we are working on the rest of the comments you had sent here is our e= xplanation for using the '-D_H_FLOAT=E2=80=99 flag in the source directory= meson.build file. >> + # This flag is required to make sure the user spefic float.h is >> + # picked instead of the system float.h header file, which doesnot >> + # have definition like float8, etc >> + cflags +=3D '-D_H_FLOAT=E2=80=99 >I don't understand this one - how does defining _H_FLOAT lead to a >differ= ent >header being picked? Also, float8 is defined in c.h, so it hardly could >be >influenced by a system float.h header? >Our float.h header is only included as "utils/float.h", so it really >shou= ldn=E2=80=99t >be confused with a system header? So If we do not use the flag the error we get is as follows, FAILED: src/backend/utils/activity/wait_event_names.a.p/wait_event_funcs.c.o gcc -Isrc/backend/utils/activity/wait_event_names.a.p -Isrc/include/utils -= I../src/include/utils -Isrc/include -I../src/include -I/opt/freeware/includ= e -I/opt/freeware/include/libxml2 -fdiagnostics-color=3Dalways -D_FILE_OFFS= ET_BITS=3D64 -Wall -Winvalid-pch -O2 -g -fno-strict-aliasing -fwrapv -fexce= ss-precision=3Dstandard -Wmissing-prototypes -Wpointer-arith -Werror=3Dvla = -Wendif-labels -Wmissing-format-attribute -Wimplicit-fallthrough=3D3 -Wcast= -function-type -Wshadow=3Dcompatible-local -Wformat-security -Wdeclaration-= after-statement -Wno-format-truncation -Wno-stringop-truncation -maix64 -fP= IC -pthread -DBUILDING_DLL1233 -MD -MQ src/backend/utils/activity/wait_even= t_names.a.p/wait_event_funcs.c.o -MF src/backend/utils/activity/wait_event_= names.a.p/wait_event_funcs.c.o.d -o src/backend/utils/activity/wait_event_n= ames.a.p/wait_event_funcs.c.o -c ../src/backend/utils/activity/wait_event_f= uncs.c In file included from /usr/include/sys/limits.h:307, from /opt/freeware/lib/gcc/powerpc-ibm-aix7.3.0.0/13/inclu= de-fixed/stdio.h:589, from ../src/include/c.h:65, from ../src/include/postgres.h:48, from ../src/backend/utils/activity/wait_event_funcs.c:15: ../src/include/utils/float.h:28:19: error: expected ';' before 'int' 28 | extern PGDLLIMPORT int extra_float_digits; ../src/include/utils/float.h:289:37: error: unknown type name 'float4' 289 | float4_min(const float4 val1, const float4 val2) ../src/include/utils/float.h:294:15: error: unknown type name 'float8' 294 | static inline float8 The reason this happened is because -I../src/include/utils argument in the = command included the float.h header first before the ./src/include/c.h head= er of postgresql which actually has the PGDLLIMPORT, float4 and float8 definitions. So, the header files have mismatched in the order they are processed. If we= eliminate -I../src/include/utils in the command, then it will work. But that will not happen automatically since we use include_directories() e= verywhere which adds both the source and the build directory includes. If w= e can get meson to not use -I../src/include/ in AIX while including headers we will be able to compile. We are currently experimenting with implicit_include_directories from the d= ocument below to see if we can remove the same https://mesonbuild.com/Include-directories.html. Reason for -D_H_FLOAT This prevents AIX libc=E2=80=99s float.h to be included via c.h -> stdio.h = -> limits.h -> float.h. The real problem is header include order in AIX. Co= mpiler sees src/include/utils/float.h first and then c.h. This is a problem= . When this flag is set, AIX=E2=80=99s float.h is skipped causing system he= ader include chain to change. AIX no longer injects float.h early which res= ults in c.h included before utils/float.h. the way Postgres expects. Let us know what you think. Is there a preferred or cleaner way you know to ensure the correct include = ordering like using implicit_include_directories so that utils/float.h is n= ot included before c.h? Have a nice day ahead. Thanks and regards, Aditya. From: Srirama Kucherlapati Date: Wednesday, 28 January 2026 at 9:34=E2=80=AFAM To: Aditya Kamath Subject: FW: [EXTERNAL] Re: AIX support FYI Warm regards, Sriram. ------------------------------------------ VIOS/SSP Development, ISDL, IBM India Pvt Ltd. From: Andres Freund Date: Monday, 26 January 2026 at 21:11 To: Srirama Kucherlapati Cc: Peter Eisentraut , pgsql-hackers@lists.postgresql= .org , Heikki Linnakangas , Tristan Partin , AIX PG user Subject: [EXTERNAL] Re: AIX support Hi, From what I can tell the meson patch *AGAIN* is missing mkldexport.sh. Also, you seem to reference the script as files('port/aix/mkldexport.sh'), but th= at that's not a path that makes sense for our source code structure (nor where the "complete" patch adds it). You really need to actually start testing your patches. Doesn't the meson patch also require the changes to src/tools/gen_export.pl? On 2026-01-23 16:11:25 +0000, Srirama Kucherlapati wrote: > diff --git a/meson.build b/meson.build > index 6e7ddd74683..17ad9c6ca32 100644 > --- a/meson.build > +++ b/meson.build > @@ -198,6 +198,8 @@ endif > # that purpose. > portname =3D host_system > > +dep_static_lib =3D declare_dependency() Add a comment saying something like # In some configurations we don't want to install static libraries. For tho= se # dep_static_lib can be set to disabler() below. The introduction of dep_static_lib should be broken out into its own patch. > + # This flag is required to make sure the user spefic float.h is > + # picked instead of the system float.h header file, which doesnot > + # have definition like float8, etc > + cflags +=3D '-D_H_FLOAT' I don't understand this one - how does defining _H_FLOAT lead to a different header being picked? Also, float8 is defined in c.h, so it hardly could be influenced by a system float.h header? Our float.h header is only included as "utils/float.h", so it really should= n't be confused with a system header? > @@ -1765,10 +1793,49 @@ endforeach > # as long, char, short, or int. Note that we intentionally do not consi= der > # 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 =3D cdata.get('ALIGNOF_DOUBLE') > -if cc.alignment('int64_t', args: test_c_args, prefix: '#include ') > alignof_double > - error('alignment of int64_t is greater than the alignment of double') > -endif > +if host_system !=3D 'aix' > + alignof_double =3D cdata.get('ALIGNOF_DOUBLE') > + if cc.alignment('int64_t', args: test_c_args, prefix: '#include ') > alignof_double > + error('alignment of int64_t is greater than the alignment of doub= le') > + endif > +else > + # The AIX 'power' alignment rules apply the natural alignment of the "= first > + # member" if it is of a floating-point data type (or is an aggregate w= hose > + # recursively "first" member or element is such a type). The alignment > + # associated with these types for subsequent members use an alignment = value > + # where the floating-point data type is considered to have 4-byte alig= nment. > + # More info > + # https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D99557=20 > + # > + # The double is aligned to 4-bytes on AIX in aggregates. But to mainta= in > + # alignement across platforms the max alignment of long should be cons= idered. How are these "AIX 'power' alignment rules" for float not just completely broken? I assume this means that 4 byte aligned floats work just fine, but have degraded peformance? Is there documentation about this that isn't an already fixed bug report in= gcc? Maybe I'm confused, but doesn't this power alignment rule mean that the cc.alignment('double') will always return 8? That computation won't apply t= he "subsequent member" rule, and therefore will have an alignment of 8. Which = in turn seems to make this entire change pointless? > + # Get the alignment values > + ac_cv_alignof_long =3D cc.alignment('long', args: test_c_args, pref= ix: '#include ') > + ac_cv_alignof_double =3D cc.alignment('double', args: test_c_args, pr= efix: '#include ') > + ac_cv_alignof_int64_t =3D cc.alignment('int64_t', args: test_c_args, p= refix: '#include ') I've previously complained about these av_cv_ variable names. This isn't autoconf. What is this doing here? Why do we need a platform specific alignment determination for long, int64? > + message('Alignment of long : @0@'.format(ac_cv_alignof_long)) > + message('Alignment of double : @0@'.format(ac_cv_alignof_double)) > + message('Alignment of int64_t : @0@'.format(ac_cv_alignof_int64_t)) These are already going to be output by cc.alignment, this is just redundan= t, no? > + # Start with long > + alignof_double =3D ac_cv_alignof_long > + message('MAX ALIGN ac_cv_alignof_long') > + > + # Compare with double > + if alignof_double < ac_cv_alignof_double > + alignof_double =3D ac_cv_alignof_double > + message('MAX ALIGN ac_cv_alignof_double') > + endif > + > + # Compare with int64_t > + if alignof_double < ac_cv_alignof_int64_t > + alignof_double =3D ac_cv_alignof_int64_t > + message('MAX ALIGN ac_cv_alignof_int64_t') > + endif > +endif > +message('MAX ALIGN OF DOUBLE : @0@'.format(alignof_double)) This is a lot of output for something that's just computing a maximum of th= ree variables. > diff --git a/src/backend/meson.build b/src/backend/meson.build > index b831a541652..4838f245ab3 100644 > --- a/src/backend/meson.build > +++ b/src/backend/meson.build > @@ -125,6 +125,24 @@ if host_system =3D=3D 'windows' > '--FILEDESC', 'PostgreSQL Server',]) > endif > > +if host_system =3D=3D 'aix' > + # The '.' argument leads mkldexport.sh to emit "#! .", which refers to= the > + # main executable, allowing extension libraries to resolve their undef= ined > + # symbols to symbols in the postgres binary. > + postgres_imp =3D 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 +=3D '-Wl,-bE:@0@'.format(postgres_imp.full_path()) > + backend_link_depends +=3D postgres_imp > +endif This should be moved next to the msvc specific block (the one about postgres_def) and should use an elif. Greetings, Andres Freund --_000_LV8PR15MB64883FC333B351ABD169E874D691ALV8PR15MB6488namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
Hi Andrew,

Thank you for your review comments for AIX so far.

While we are working on the rest of the comments you had sent here is our e= xplanation for using the  '-D_H_FLOAT=E2=80=99 flag in the source dire= ctory meson.build file.

>> +&nb= sp; # This flag is required to make sure the user spefic float.h is<= span style=3D"font-family: Aptos, Arial, Helvetica, sans-serif; font-size: = 12pt; color: rgb(0, 0, 0);">
>> +  # picked instead of = the system float.h header file, which doesnot
>> +  # have definition li= ke float8, etc
>> +  cflags +=3D '-D= _H_FLOAT=E2=80=99

>I don't understand this one - how does d= efining _H_FLOAT lead to a >different
>header being picked? Also, float8= is defined in c.h, so it hardly could >be
>influenced by a system float.h he= ader?

>Our float.h header is only included as "utils/floa= t.h", so it really >shouldn=E2=80=99t
>be confused with a system header?=


So If we do not use the flag the error we get is as follows,

FAILED: src/backend/utils/activity/wait_event_names.a.p/wait_event_funcs.c.= o 
gcc -Isrc/backend/utils/activity/wait_event_names.a.p -Isrc/include/utils -= I../src/include/utils -Isrc/include -I../src/include -I/opt/freeware/i= nclude -I/opt/freeware/include/libxml2 -fdiagnostics-color=3Dalways -D_FILE= _OFFSET_BITS=3D64 -Wall -Winvalid-pch -O2 -g -fno-strict-aliasing -fwrapv -fexcess-precision=3Dstandard -Wmissing-pr= ototypes -Wpointer-arith -Werror=3Dvla -Wendif-labels -Wmissing-format-attr= ibute -Wimplicit-fallthrough=3D3 -Wcast-function-type -Wshadow=3Dcompatible= -local -Wformat-security -Wdeclaration-after-statement -Wno-format-truncation -Wno-stringop-truncation -maix64 -fPIC -pthread -DB= UILDING_DLL1233 -MD -MQ src/backend/utils/activity/wait_event_names.a.p/wai= t_event_funcs.c.o -MF src/backend/utils/activity/wait_event_names.a.p/wait_= event_funcs.c.o.d -o src/backend/utils/activity/wait_event_names.a.p/wait_e= vent_funcs.c.o -c ../src/backend/utils/activity/wait_event_funcs.c
In file included from /usr/include/sys/limits.h:307,
                 from /opt/fre= eware/lib/gcc/powerpc-ibm-aix7.3.0.0/13/include-fixed/stdio.h:589,
                 from ../src/i= nclude/c.h:65,
                 from ../src/i= nclude/postgres.h:48,
                 from ../src/b= ackend/utils/activity/wait_event_funcs.c:15:
../src/include/utils/float.h:28:19: error: expected ';' before 'int'
   28 | extern PGDLLIMPORT int extra_float_digits;
../src/include/utils/float.h:289:37: error: unknown type name 'float4'
  289 | float4_min(const float4 val1, const float4 val2)
../src/include/utils/float.h:294:15: error: unknown type name 'float8'
  294 | static inline float8

The reason this happened is because -I../src/include/utils argument in the = command included the float.h header first before the ./src/include/c.h head= er of postgresql which actually has the 
PGDLLIMPORT, float4 and float8 definitions. 

So, the header files have m= ismatched in the order they are processed. If we eliminate -I../src/include= /utils in the command, then it will work. 

But th= at will not happen automatically since we use include_directories() everywh= ere which adds both the source and the build directory includes. If we can = get meson to not use 
-I../s= rc/include/ in AIX while including headers we will be able to compile. = ;

We are currently experimenting with implicit_include_director= ies from the document below to see if we can remove the same 

Reason= for -D_H_FLOAT

This p= revents AIX libc=E2=80=99s float.h to be included via c.h -> stdio.h -&g= t; limits.h -> float.h. The real problem is header include order in AIX.= Compiler sees src/include/utils/float.h first and then c.h. This is a problem. When this flag is set, AIX=E2=80=99s float.h = is skipped causing system header include chain to change. AIX no longer inj= ects float.h early which results in c.h included before utils/float.h. the = way Postgres expects.

Let us= know what you think.

Is there a preferred or cleaner way you know t= o ensure the correct include ordering like using implicit_include_directories so that utils/float.h is not included before c.h?

Have a nice day ahead.

Thanks and regards,
Aditya.

 =

From: Srirama Kucherlapati <sriram.rk@in.ibm.com>
Date: Wednesday, 28 January 2026 at 9:34=E2=80=AFAM
To: Aditya Kamath <Aditya.Kamath1@ibm.com>
Subject: FW: [EXTERNAL] Re: AIX support

FYI

Warm regards,

Sriram.

 

From: Andres Freund <andres@anarazel.de>
Date: Monday, 26 January 2026 at 21:11
To: Srirama Kucherlapati <sriram.rk@in.ibm.com>
Cc: Peter Eisentraut <peter@eisentraut.org>, pgsql-hackers@lists.postgresql.or= g <pgsql-hackers@lists.postgresql.org>, Heikki Linnakangas <hlinna= ka@iki.fi>, Tristan Partin <tristan@partin.io>, AIX PG user <postgres-ibm-aix@wwpdl.vnet.ibm.com>
Subject: [EXTERNAL] Re: AIX support

Hi,

From what I can tell the meson patch *AGAIN* is missing mkldexport.sh. Also= ,
you seem to reference the script as files('port/aix/mkldexport.sh'), but th= at
that's not a path that makes sense for our source code structure (nor where=
the "complete" patch adds it).

You really need to actually start testing your patches.


Doesn't the meson patch also require the changes to src/tools/gen_export.pl= ?


On 2026-01-23 16:11:25 +0000, Srirama Kucherlapati wrote:
> diff --git a/meson.build b/meson.build
> index 6e7ddd74683..17ad9c6ca32 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -198,6 +198,8 @@ endif
>  # that purpose.
>  portname =3D host_system
>
> +dep_static_lib =3D declare_dependency()

Add a comment saying something like

# In some configurations we don't want to install static libraries. For tho= se
# dep_static_lib can be set to disabler() below.


The introduction of dep_static_lib should be broken out into its own patch.=



> +  # This flag is required to make sure the user spefic float.h i= s
> +  # picked instead of the system float.h header file, which does= not
> +  # have definition like float8, etc
> +  cflags +=3D '-D_H_FLOAT'

I don't understand this one - how does defining _H_FLOAT lead to a differen= t
header being picked? Also, float8 is defined in c.h, so it hardly could be<= br> influenced by a system float.h header?

Our float.h header is only included as "utils/float.h", so it rea= lly shouldn't
be confused with a system header?


> @@ -1765,10 +1793,49 @@ endforeach
>  # as long, char, short, or int.  Note that we intentionally= do not consider
>  # any types wider than 64 bits, as allowing MAXIMUM_ALIGNOF to e= xceed 8
>  # would be too much of a penalty for disk and memory space.
> -alignof_double =3D cdata.get('ALIGNOF_DOUBLE')
> -if cc.alignment('int64_t', args: test_c_args, prefix: '#include <s= tdint.h>') > alignof_double
> -  error('alignment of int64_t is greater than the alignment of d= ouble')
> -endif
> +if host_system !=3D 'aix'
> +  alignof_double =3D cdata.get('ALIGNOF_DOUBLE')
> +  if cc.alignment('int64_t', args: test_c_args, prefix: '#includ= e <stdint.h>') > alignof_double
> +       error('alignment of int64_t is g= reater than the alignment of double')
> +  endif
> +else
> +  # The AIX 'power' alignment rules apply the natural alignment = of the "first
> +  # member" if it is of a floating-point data type (or is a= n aggregate whose
> +  # recursively "first" member or element is such a ty= pe). The alignment
> +  # associated with these types for subsequent members use an al= ignment value
> +  # where the floating-point data type is considered to have 4-b= yte alignment.
> +  # More info
> +  # https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__gcc.gnu.org_bugzilla= _show-5Fbug.cgi-3Fid-3D99557&d=3DDwIBAg&c=3DBSDicqBQBDjDI9RkVyTcHQ&= amp;r=3DvAjXYU48syuVpPwT4QhmwXMV4E--HIOXIW0gSQS4cHk&m=3DspxpHlbU-oUOjZW= tuXCtkVhprvgA3G5mhMCfcMRz7RhvcqbJQbX0erzJ-MgCiBKp&s=3Dcdf4qUM5zjhQjv8rA= Uj5eMnRTtNyjaOEuuJFiHMu0uY&e=3D
> +  #
> +  # The double is aligned to 4-bytes on AIX in aggregates. But t= o maintain
> +  # alignement across platforms the max alignment of long should= be considered.

How are these "AIX 'power' alignment rules" for float not just co= mpletely
broken?

I assume this means that 4 byte aligned floats work just fine, but have
degraded peformance?

Is there documentation about this that isn't an already fixed bug report in= gcc?


Maybe I'm confused, but doesn't this power alignment rule mean that the
cc.alignment('double') will always return 8? That computation won't apply t= he
"subsequent member" rule, and therefore will have an alignment of= 8. Which in
turn seems to make this entire change pointless?


> +  # Get the alignment values
> +  ac_cv_alignof_long    =3D cc.alignment('long', = args: test_c_args, prefix: '#include <stdint.h>')
> +  ac_cv_alignof_double  =3D cc.alignment('double', args: te= st_c_args, prefix: '#include <stdint.h>')
> +  ac_cv_alignof_int64_t =3D cc.alignment('int64_t', args: test_c= _args, prefix: '#include <stdint.h>')

I've previously complained about these av_cv_ variable names. This isn't
autoconf. What is this doing here?

Why do we need a platform specific alignment determination for long, int64?=


> +  message('Alignment of long    : @0@'.format(ac_= cv_alignof_long))
> +  message('Alignment of double  : @0@'.format(ac_cv_alignof= _double))
> +  message('Alignment of int64_t : @0@'.format(ac_cv_alignof_int6= 4_t))

These are already going to be output by cc.alignment, this is just redundan= t,
no?


> +  # Start with long
> +  alignof_double =3D ac_cv_alignof_long
> +  message('MAX ALIGN ac_cv_alignof_long')
> +
> +  # Compare with double
> +  if alignof_double < ac_cv_alignof_double
> +    alignof_double =3D ac_cv_alignof_double
> +    message('MAX ALIGN ac_cv_alignof_double')
> +  endif
> +
> +  # Compare with int64_t
> +  if alignof_double < ac_cv_alignof_int64_t
> +    alignof_double =3D ac_cv_alignof_int64_t
> +    message('MAX ALIGN ac_cv_alignof_int64_t')
> +  endif
> +endif
> +message('MAX ALIGN OF DOUBLE : @0@'.format(alignof_double))

This is a lot of output for something that's just computing a maximum of th= ree
variables.



> diff --git a/src/backend/meson.build b/src/backend/meson.build
> index b831a541652..4838f245ab3 100644
> --- a/src/backend/meson.build
> +++ b/src/backend/meson.build
> @@ -125,6 +125,24 @@ if host_system =3D=3D 'windows'
>      '--FILEDESC', 'PostgreSQL Server',])
>  endif
>
> +if host_system =3D=3D 'aix'
> +  # The '.' argument leads mkldexport.sh to emit "#! ."= ;, which refers to the
> +  # main executable, allowing extension libraries to resolve the= ir undefined
> +  # symbols to symbols in the postgres binary.
> +  postgres_imp =3D 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 +=3D '-Wl,-bE:@0@'.format(postgres_imp.full_= path())
> +  backend_link_depends +=3D postgres_imp
> +endif

This should be moved next to the msvc specific block (the one about
postgres_def) and should use an elif.



Greetings,

Andres Freund
--_000_LV8PR15MB64883FC333B351ABD169E874D691ALV8PR15MB6488namp_--