Re: Relation bulk write facility

Noah Misch <noah@leadboat.com>

From: Noah Misch <noah@leadboat.com>
To: Heikki Linnakangas <hlinnaka@iki.fi>
Cc: Thomas Munro <thomas.munro@gmail.com>, Andres Freund <andres@anarazel.de>, Peter Smith <smithpb2250@gmail.com>, Robert Haas <robertmhaas@gmail.com>, vignesh C <vignesh21@gmail.com>, pgsql-hackers <pgsql-hackers@postgresql.org>, Melanie Plageman <melanieplageman@gmail.com>
Date: 2024-02-25T19:43:22Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Relax fsyncing at end of a bulk load that was not WAL-logged

  2. Fix cross-version upgrade tests after f0827b443.

  3. Remove AIX support

  4. Fix compiler warning on typedef redeclaration

  5. Introduce a new smgr bulk loading facility.

Attachments

On Sun, Feb 25, 2024 at 04:34:47PM +0200, Heikki Linnakangas wrote:
> I agree with Andres though, that unless someone raises their hand and
> volunteers to properly maintain the AIX support, we should drop it.

There's no way forward in which AIX support stops doing net harm.  Even if AIX
enthusiasts intercepted would-be buildfarm failures and fixed them before
buildfarm.postgresql.org could see them, the damage from the broader community
seeing the AIX-specific code would outweigh the benefits of AIX support.  I've
now disabled the animals for v17+, though each may do one more run before
picking up the disable.

My upthread observation about xcoff section alignment was a red herring.  gcc
populates symbol-level alignment, and section-level alignment is unnecessary
if symbol-level alignment is correct.  The simplest workaround for $SUBJECT
AIX failure would be to remove the "const", based on the results of the
attached test program.  The pg_prewarm.c var is like al4096_static in the
outputs below, hence the lack of trouble there.  The bulk_write.c var is like
al4096_static_const_initialized.

==== gcc 8.3.0
al4096                           4096 @ 0x11000c000 (mod 0)
al4096_initialized               4096 @ 0x110000fd0 (mod 4048 - BUG)
al4096_const                     4096 @ 0x11000f000 (mod 0)
al4096_const_initialized         4096 @ 0x10000cd00 (mod 3328 - BUG)
al4096_static                    4096 @ 0x110005000 (mod 0)
al4096_static_initialized        4096 @ 0x110008000 (mod 0)
al4096_static_const              4096 @ 0x100000c10 (mod 3088 - BUG)
al4096_static_const_initialized  4096 @ 0x100003c10 (mod 3088 - BUG)
==== xlc 12.01.0000.0000
al4096                           4096 @ 0x110008000 (mod 0)
al4096_initialized               4096 @ 0x110004000 (mod 0)
al4096_const                     4096 @ 0x11000b000 (mod 0)
al4096_const_initialized         4096 @ 0x100007000 (mod 0)
al4096_static                    4096 @ 0x11000e000 (mod 0)
al4096_static_initialized        4096 @ 0x110001000 (mod 0)
al4096_static_const              4096 @ 0x110011000 (mod 0)
al4096_static_const_initialized  4096 @ 0x1000007d0 (mod 2000 - BUG)
==== ibm-clang 17.1.1.2
al4096                           4096 @ 0x110001000 (mod 0)
al4096_initialized               4096 @ 0x110004000 (mod 0)
al4096_const                     4096 @ 0x100001000 (mod 0)
al4096_const_initialized         4096 @ 0x100005000 (mod 0)
al4096_static                    4096 @ 0x110008000 (mod 0)
al4096_static_initialized        4096 @ 0x11000b000 (mod 0)
al4096_static_const              4096 @ 0x100009000 (mod 0)
al4096_static_const_initialized  4096 @ 0x10000d000 (mod 0)