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)