Re: Relation bulk write facility

From: Noah Misch <noah(at)leadboat(dot)com>
To: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
Cc: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Peter Smith <smithpb2250(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, vignesh C <vignesh21(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Melanie Plageman <melanieplageman(at)gmail(dot)com>
Subject: Re: Relation bulk write facility
Date: 2024-02-24 19:50:24
Message-ID: 20240224195024.af@rfd.leadboat.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, Feb 25, 2024 at 07:52:16AM +1300, Thomas Munro wrote:
> On Sun, Feb 25, 2024 at 6:24 AM Noah Misch <noah(at)leadboat(dot)com> wrote:
> > On Fri, Feb 23, 2024 at 04:27:34PM +0200, Heikki Linnakangas wrote:
> > > Committed this. Thanks everyone!
> >
> > https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=mandrill&dt=2024-02-24%2015%3A13%3A14 got:
> > TRAP: failed Assert("(uintptr_t) buffer == TYPEALIGN(PG_IO_ALIGN_SIZE, buffer)"), File: "md.c", Line: 472, PID: 43188608
> >
> > with this stack trace:
> > #5 0x10005cf0 in ExceptionalCondition (conditionName=0x1015d790 <XLogBeginInsert+80> "`", fileName=0x0, lineNumber=16780064) at assert.c:66
> > #6 0x102daba8 in mdextend (reln=0x1042628c <PageSetChecksumInplace+44>, forknum=812540744, blocknum=33, buffer=0x306e6000, skipFsync=812539904) at md.c:472
> > #7 0x102d6760 in smgrextend (reln=0x306e6670, forknum=812540744, blocknum=33, buffer=0x306e6000, skipFsync=812539904) at smgr.c:541
> > #8 0x104c8dac in smgr_bulk_flush (bulkstate=0x306e6000) at bulk_write.c:245
>
> So that's:
>
> static const PGIOAlignedBlock zero_buffer = {{0}}; /* worth BLCKSZ */
>
> ...
> smgrextend(bulkstate->smgr, bulkstate->forknum,
> bulkstate->pages_written++,
> &zero_buffer,
> true);
>
> ... where PGIOAlignedBlock is:
>
> typedef union PGIOAlignedBlock
> {
> #ifdef pg_attribute_aligned
> pg_attribute_aligned(PG_IO_ALIGN_SIZE)
> #endif
> char data[BLCKSZ];
> ...
>
> We see this happen with both xlc and gcc (new enough to know how to do
> this). One idea would be that the AIX *linker* is unable to align it,
> as that is the common tool-chain component here (and unlike stack and
> heap objects, this scope is the linker's job). There is a
> pre-existing example of a zero-buffer that is at file scope like that:
> pg_prewarm.c. Perhaps it doesn't get tested?
>
> Hmm.

GCC docs do say "For some linkers, the maximum supported alignment may be very
very small.", but AIX "man LD" says "data sections are aligned on a boundary
so as to satisfy the alignment of all CSECTs in the sections". It also has -H
and -K flags to force some particular higher alignment.

On GNU/Linux x64, gcc correctly records alignment=2**12 for the associated
section (.rodata for bulk_write.o zero_buffer, .bss for pg_prewarm.o
blockbuffer). If I'm reading this right, neither AIX gcc nor xlc is marking
the section with sufficient alignment, in bulk_write.o or pg_prewarm.o:

$ /opt/cfarm/binutils-latest/bin/objdump --section-headers ~/farm/*/HEAD/pgsqlkeep.*/src/backend/storage/smgr/bulk_write.o

/home/nm/farm/gcc64/HEAD/pgsqlkeep.2024-02-24_00-03-22/src/backend/storage/smgr/bulk_write.o: file format aix5coff64-rs6000

Sections:
Idx Name Size VMA LMA File off Algn
0 .text 0000277c 0000000000000000 0000000000000000 000000f0 2**2
CONTENTS, ALLOC, LOAD, RELOC, CODE
1 .data 000000e4 000000000000277c 000000000000277c 0000286c 2**3
CONTENTS, ALLOC, LOAD, RELOC, DATA
2 .debug 0001f7ea 0000000000000000 0000000000000000 00002950 2**3
CONTENTS

/home/nm/farm/xlc32/HEAD/pgsqlkeep.2024-02-24_15-12-23/src/backend/storage/smgr/bulk_write.o: file format aixcoff-rs6000

Sections:
Idx Name Size VMA LMA File off Algn
0 .text 00000880 00000000 00000000 00000180 2**2
CONTENTS, ALLOC, LOAD, RELOC, CODE
1 .data 0000410c 00000880 00000880 00000a00 2**3
CONTENTS, ALLOC, LOAD, RELOC, DATA
2 .bss 00000000 0000498c 0000498c 00000000 2**3
ALLOC
3 .debug 00008448 00000000 00000000 00004b24 2**3
CONTENTS
4 .except 00000018 00000000 00000000 00004b0c 2**3
CONTENTS, LOAD

$ /opt/cfarm/binutils-latest/bin/objdump --section-headers ~/farm/*/HEAD/pgsqlkeep.*/contrib/pg_prewarm/pg_prewarm.o

/home/nm/farm/gcc32/HEAD/pgsqlkeep.2024-01-21_03-16-12/contrib/pg_prewarm/pg_prewarm.o: file format aixcoff-rs6000

Sections:
Idx Name Size VMA LMA File off Algn
0 .text 00000a6c 00000000 00000000 000000b4 2**2
CONTENTS, ALLOC, LOAD, RELOC, CODE
1 .data 00000044 00000a6c 00000a6c 00000b20 2**3
CONTENTS, ALLOC, LOAD, RELOC, DATA
2 .bss 00002550 00000ab0 00000ab0 00000000 2**3
ALLOC
3 .debug 0001c50e 00000000 00000000 00000b64 2**3
CONTENTS

/home/nm/farm/gcc64/HEAD/pgsqlkeep.2024-02-15_17-13-04/contrib/pg_prewarm/pg_prewarm.o: file format aix5coff64-rs6000

Sections:
Idx Name Size VMA LMA File off Algn
0 .text 00000948 0000000000000000 0000000000000000 00000138 2**2
CONTENTS, ALLOC, LOAD, RELOC, CODE
1 .data 00000078 0000000000000948 0000000000000948 00000a80 2**3
CONTENTS, ALLOC, LOAD, RELOC, DATA
2 .bss 00002640 00000000000009c0 00000000000009c0 00000000 2**3
ALLOC
3 .debug 0001d887 0000000000000000 0000000000000000 00000af8 2**3
CONTENTS

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Munro 2024-02-24 20:12:43 Re: Relation bulk write facility
Previous Message Thomas Munro 2024-02-24 18:52:16 Re: Relation bulk write facility