Re: pgsql: Generational memory allocator

[Tom Lane]

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);