Re: Direct I/O - Mailing list pgsql-hackers

Thomas Munro <thomas.munro@gmail.com> writes:
> As far as I can tell, the failure to honour large alignment attributes
> even though the compiler passes our configure check that you can do
> that was considered to be approximately a bug[1] or at least a thing
> to be improved in fairly old GCC times but the fix wasn't back-patched
> that far.  Unfortunately the projects that were allergic to the GPL3
> change but wanted to ship a compiler (or some motivation related to
> that) got stuck on 4.2 for a while before they flipped to Clang (as
> OpenBSD has now done).  It seems hard to get excited about doing
> anything about that on our side, and those systems are also spewing
> other warnings.  But if we're going to do it, it looks like the right
> place would indeed be a new compiler check that the attribute exists
> *and* generates no warnings with alignment > 16, something like that?

I tested this by building gcc 4.2.1 from source on modern Linux
(which was a bit more painful than it ought to be, perhaps)
and building PG with that.  It generates no warnings, but nonetheless
gets an exception in CREATE DATABASE:

#2  0x0000000000b64522 in ExceptionalCondition (
    conditionName=0xd4fca0 "(uintptr_t) buffer == TYPEALIGN(PG_IO_ALIGN_SIZE, buffer)", fileName=0xd4fbe0 "md.c",
lineNumber=468)at assert.c:66 
#3  0x00000000009a6b53 in mdextend (reln=0x1dcaf68, forknum=MAIN_FORKNUM,
    blocknum=18, buffer=0x7ffcaf8e1af0, skipFsync=true) at md.c:468
#4  0x00000000009a9075 in smgrextend (reln=0x1dcaf68, forknum=MAIN_FORKNUM,
    blocknum=18, buffer=0x7ffcaf8e1af0, skipFsync=true) at smgr.c:500
#5  0x000000000096739c in RelationCopyStorageUsingBuffer (srclocator=...,
    dstlocator=..., forkNum=MAIN_FORKNUM, permanent=true) at bufmgr.c:4286
#6  0x0000000000967584 in CreateAndCopyRelationData (src_rlocator=...,
    dst_rlocator=..., permanent=true) at bufmgr.c:4361
#7  0x000000000068898e in CreateDatabaseUsingWalLog (src_dboid=1,
    dst_dboid=24576, src_tsid=1663, dst_tsid=1663) at dbcommands.c:217
#8  0x000000000068b594 in createdb (pstate=0x1d4a6a8, stmt=0x1d20ec8)
    at dbcommands.c:1441

Sure enough, that buffer is a stack local in
RelationCopyStorageUsingBuffer, and it's visibly got a
not-very-well-aligned address.

So apparently, the fact that you even get a warning about the
alignment not being honored is something OpenBSD patched in
after-the-fact; it's not there in genuine vintage gcc.

I get the impression that we are going to need an actual runtime
test if we want to defend against this.  Not entirely convinced
it's worth the trouble.  Who, other than our deliberately rear-guard
buildfarm animals, is going to be building modern PG with such old
compilers?  (And more especially to the point, on platforms new
enough to have working O_DIRECT?)

At this point I agree with Andres that it'd be good enough to
silence the warning by getting rid of these alignment pragmas
when the platform lacks O_DIRECT.

            regards, tom lane

PS: I don't quite understand how it managed to get through initdb
when CREATE DATABASE doesn't work.  Maybe there is a different
code path taken in standalone mode?