8000 Pad XLogReaderState's main_data buffer more aggressively. · koderP/postgres@c0ef3af · GitHub
[go: up one dir, main page]

Skip to content

Commit c0ef3af

Browse files
committed
Pad XLogReaderState's main_data buffer more aggressively.
Originally, we palloc'd this buffer just barely big enough to hold the largest xlog record seen so far. It turns out that that can result in valgrind complaints, because some compilers will emit code that assumes it can safely fetch padding bytes at the end of a struct, and those padding bytes were unallocated so far as aset.c was concerned. We can fix that by MAXALIGN'ing the palloc request size, ensuring that it is big enough to include any possible padding that might've been omitted from the on-disk record. An additional objection to the original coding is that it could result in many repeated palloc cycles, in the worst case where we see a series of gradually larger xlog records. We can ameliorate that cheaply by imposing a minimum buffer size that's large enough for most xlog records. BLCKSZ/2 was chosen after a bit of discussion. In passing, remove an obsolete comment in struct xl_heap_new_cid that the combocid field is free due to alignment considerations. Perhaps that was true at some point, but it's not now. Back-patch to 9.5 where this code came in. Discussion: https://postgr.es/m/E1eHa4J-0006hI-Q8@gemulon.postgresql.org
1 parent db714c6 commit c0ef3af

File tree

2 files changed

+17
-8
lines changed

2 files changed

+17
-8
lines changed

src/backend/access/transam/xlogreader.c

Lines changed: 16 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1248,7 +1248,22 @@ DecodeXLogRecord(XLogReaderState *state, XLogRecord *record, char **errormsg)
12481248
{
12491249
if (state->main_data)
12501250
pfree(state->main_data);
1251-
state->main_data_bufsz = state->main_data_len;
1251+
1252+
/*
1253+
* main_data_bufsz must be MAXALIGN'ed. In many xlog record
1254+
* types, we omit trailing struct padding on-disk to save a few
1255+
* bytes; but compilers may generate accesses to the xlog struct
1256+
* that assume that padding bytes are present. If the palloc
1257+
* request is not large enough to include such padding bytes then
1258+
* we'll get valgrind complaints due to otherwise-harmless fetches
1259+
* of the padding bytes.
1260+
*
1261+
* In addition, force the initial request to be reasonably large
1262+
* so that we don't waste time with lots of trips through this
1263+
* stanza. BLCKSZ / 2 seems like a good compromise choice.
1264+
*/
1265+
state->main_data_bufsz = MAXALIGN(Max(state->main_data_len,
1266+
BLCKSZ / 2));
12521267
state->main_data = palloc(state->main_data_bufsz);
12531268
}
12541269
memcpy(state->main_data, ptr, state->main_data_len);

src/include/access/heapam_xlog.h

Lines changed: 1 addition & 7 deletions
Original file line numberDiff line numberDiff line change
@@ -333,13 +333,7 @@ typedef struct xl_heap_new_cid
333333
TransactionId top_xid;
334334
CommandId cmin;
335335
CommandId cmax;
336-
337-
/*
338-
* don't really need the combocid since we have the actual values right in
339-
* this struct, but the padding makes it free and its useful for
340-
* debugging.
341-
*/
342-
CommandId combocid;
336+
CommandId combocid; /* just for debugging */
343337

344338
/*
345339
* Store the relfilenode/ctid pair to facilitate lookups.

0 commit comments

Comments
 (0)
0