Pad XLogReaderState's per-buffer data_bufsz more aggressively.

Originally, we palloc'd this buffer just barely big enough to hold the
largest xlog backup block seen so far. We now MAXALIGN the palloc size.

The original coding could result in many repeated palloc cycles, in the
worst case where we see a series ofgradually larger xlog records.  We
ameliorate that similarly to 8735978e7aebfbc499843630131c18d1f7346c79
by imposing a minimum buffer size of BLCKSZ.

Discussion: https://postgr.es/m/E1eHa4J-0006hI-Q8@gemulon.postgresql.org

diff --git a/src/backend/access/transam/xlogreader.c b/src/backend/access/transam/xlogreader.c
index fa9432eb67777009428b1e53b4a9501a8395c511..0a75c360260649be94783e7310cfcde9f4f9f6cc 100644 (file)
--- a/src/backend/access/transam/xlogreader.c
+++ b/src/backend/access/transam/xlogreader.c
@@ -1264,7 +1264,13 @@ DecodeXLogRecord(XLogReaderState *state, XLogRecord *record, char **errormsg)
                        {
                                if (blk->data)
                                        pfree(blk->data);
-                               blk->data_bufsz = blk->data_len;
+
+                               /*
+                                * Force the initial request to be BLCKSZ so that we don't
+                                * waste time with lots of trips through this stanza as a
+                                * result of WAL compression.
+                                */
+                               blk->data_bufsz = MAXALIGN(Max(blk->data_len, BLCKSZ));
                                blk->data = palloc(blk->data_bufsz);
                        }
                        memcpy(blk->data, ptr, blk->data_len);