Fix another longstanding problem in copy_relation_data: it was blithely
authorTom Lane <[email protected]>
Thu, 29 Jul 2010 19:23:37 +0000 (19:23 +0000)
committerTom Lane <[email protected]>
Thu, 29 Jul 2010 19:23:37 +0000 (19:23 +0000)
assuming that a local char[] array would be aligned on at least a word
boundary.  There are architectures on which that is pretty much guaranteed to
NOT be the case ... and those arches also don't like non-aligned memory
accesses, meaning that log_newpage() would crash if it ever got invoked.
Even on Intel-ish machines there's a potential for a large performance penalty
from doing I/O to an inadequately aligned buffer.  So palloc it instead.

Backpatch to 8.0 --- 7.4 doesn't have this code.

src/backend/commands/tablecmds.c

index 3a899125a62e95f95158f124469d1455e452c3f0..d07e51fb6584a8d53d21932ce176236e7c9b0f0e 100644 (file)
@@ -8,7 +8,7 @@
  *
  *
  * IDENTIFICATION
- *       $PostgreSQL: pgsql/src/backend/commands/tablecmds.c,v 1.288.2.4 2010/07/01 14:12:04 rhaas Exp $
+ *       $PostgreSQL: pgsql/src/backend/commands/tablecmds.c,v 1.288.2.5 2010/07/29 19:23:37 tgl Exp $
  *
  *-------------------------------------------------------------------------
  */
@@ -6822,11 +6822,20 @@ static void
 copy_relation_data(SMgrRelation src, SMgrRelation dst,
                                   ForkNumber forkNum, bool istemp)
 {
+       char       *buf;
+       Page            page;
        bool            use_wal;
        BlockNumber nblocks;
        BlockNumber blkno;
-       char            buf[BLCKSZ];
-       Page            page = (Page) buf;
+
+       /*
+        * palloc the buffer so that it's MAXALIGN'd.  If it were just a local
+        * char[] array, the compiler might align it on any byte boundary, which
+        * can seriously hurt transfer speed to and from the kernel; not to
+        * mention possibly making log_newpage's accesses to the page header fail.
+        */
+       buf = (char *) palloc(BLCKSZ);
+       page = (Page) buf;
 
        /*
         * We need to log the copied data in WAL iff WAL archiving is enabled AND
@@ -6855,6 +6864,8 @@ copy_relation_data(SMgrRelation src, SMgrRelation dst,
                smgrextend(dst, forkNum, blkno, buf, true);
        }
 
+       pfree(buf);
+
        /*
         * If the rel isn't temp, we must fsync it down to disk before it's safe
         * to commit the transaction.  (For a temp rel we don't care since the rel