I wrote:
> Instead I propose that we should make sure that the palloc request size
> for XLogReaderState->main_data is always maxalign'd. The existing
> behavior in DecodeXLogRecord of palloc'ing it only just barely big
> enough for the current record seems pretty brain-dead performance-wise
> even without this consideration. Generally, if we need to enlarge
> that buffer, we should enlarge it significantly, IMO.
I've confirmed that the attached is sufficient to stop the valgrind crash
on my machine. But as I said, I think we should be more aggressive at
resizing the buffer, to reduce resize cycles. I'm inclined to start out
with a buffer size of 128 or 256 or so bytes and double it when needed.
Anybody have a feeling for a typical size for the "main data" part
of a WAL record?
regards, tom lane
diff --git a/src/backend/access/transam/xlogreader.c b/src/backend/access/transam/xlogreader.c
index aeaafed..4840b0e 100644
*** a/src/backend/access/transam/xlogreader.c
--- b/src/backend/access/transam/xlogreader.c
*************** DecodeXLogRecord(XLogReaderState *state,
*** 1279,1285 ****
{
if (state->main_data)
pfree(state->main_data);
! state->main_data_bufsz = state->main_data_len;
state->main_data = palloc(state->main_data_bufsz);
}
memcpy(state->main_data, ptr, state->main_data_len);
--- 1279,1285 ----
{
if (state->main_data)
pfree(state->main_data);
! state->main_data_bufsz = MAXALIGN(state->main_data_len);
state->main_data = palloc(state->main_data_bufsz);
}
memcpy(state->main_data, ptr, state->main_data_len);