Re: Relation bulk write facility

Committed, after fixing the various little things you pointed out:

On 28/02/2024 00:30, Thomas Munro wrote:
> --- 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, AIX, Solaris, and illumos.
> +   FreeBSD, OpenBSD, NetBSD, DragonFlyBSD, macOS, Solaris, and illumos.
> 
> There is also a little roll-of-honour of operating systems we used to
> support, just a couple of paragraphs down, where AIX should appear.

Added.

On 28/02/2024 05:52, Noah Misch wrote:
> Regardless of how someone were to step up to maintain it, we'd be telling them
> such contributions have negative value and must stop.  We're expelling AIX due
> to low demand, compiler bugs, its ABI, and its shlib symbol export needs.

Reworded.

>> Apperently the "pg_attribute_aligned(a)" attribute doesn't work on AIX
>> (linker?) for values larger than PG_IO_ALIGN_SIZE.
> 
> No; see https://postgr.es/m/20240225194322.a5%40rfd.leadboat.com

Ok, reworded.

On 28/02/2024 11:26, Andres Freund wrote:
> On 2024-02-28 00:24:01 +0400, Heikki Linnakangas wrote:
> The problem is due to this hunk:
>> @@ -401,10 +376,6 @@ 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)
>>   ifneq ($(shlib), $(shlib_major))
> 
> So the versioned name didn't end up getting installed anymore, leading to
> broken symlinks in the install directory.

Fixed, thanks!

>> diff --git a/src/bin/pg_basebackup/t/010_pg_basebackup.pl b/src/bin/pg_basebackup/t/010_pg_basebackup.pl
>> index 86cc01a640b..fc6b00224f6 100644
>> --- a/src/bin/pg_basebackup/t/010_pg_basebackup.pl
>> +++ b/src/bin/pg_basebackup/t/010_pg_basebackup.pl
>> @@ -400,9 +400,6 @@ is(scalar(@tblspc_tars), 1, 'one tablespace tar was created');
>>   SKIP:
>>   {
>>       my $tar = $ENV{TAR};
>> -    # don't check for a working tar here, to accommodate various odd
>> -    # 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 '');
> 
> Maybe better to not remove the whole comment, just the reference to AIX?

Ok, done

>> diff --git a/src/test/regress/sql/sanity_check.sql b/src/test/regress/sql/sanity_check.sql
>> index 7f338d191c6..2e9d5ebef3f 100644
>> --- a/src/test/regress/sql/sanity_check.sql
>> +++ b/src/test/regress/sql/sanity_check.sql
>> @@ -21,12 +21,15 @@ SELECT relname, relkind
>>          AND relfilenode <> 0;
>>   
>>   --
>> --- When ALIGNOF_DOUBLE==4 (e.g. AIX), the C ABI may impose 8-byte alignment on
>> +-- When MAXIMUM_ALIGNOF==8 but ALIGNOF_DOUBLE==4, the C ABI may impose 8-byte alignment
>>   -- 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.
>> +-- (XXX: I'm not sure if any of the supported platforms have MAXIMUM_ALIGNOF==8 and
>> +-- ALIGNOF_DOUBLE==4.  Perhaps we should just require that
>> +-- ALIGNOF_DOUBLE==MAXIMUM_ALIGNOF)
>>   --
>>   WITH check_columns AS (
>>    SELECT relname, attname,
> 
> I agree, this should be an error, and we should then remove the test.

Done.

-- 
Heikki Linnakangas
Neon (https://neon.tech)