pgsql: Pad XLogReaderState's main_data buffer more aggressively.

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-committers(at)postgresql(dot)org
Subject: pgsql: Pad XLogReaderState's main_data buffer more aggressively.
Date: 2017-11-26 20:17:42
Message-ID: E1eJ3N0-00021I-7e@gemulon.postgresql.org
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-committers

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

Branch
------
master

Details
-------
https://git.postgresql.org/pg/commitdiff/8735978e7aebfbc499843630131c18d1f7346c79

Modified Files
--------------
src/backend/access/transam/xlogreader.c | 17 ++++++++++++++++-
src/include/access/heapam_xlog.h | 8 +-------
2 files changed, 17 insertions(+), 8 deletions(-)

Browse pgsql-committers by date

  From Date Subject
Next Message Simon Riggs 2017-11-26 21:17:47 Re: pgsql: Generational memory allocator
Previous Message Tom Lane 2017-11-26 19:42:54 Re: pgsql: Generational memory allocator