Re: pg_verify_checksums and -fno-strict-aliasing

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: pg_verify_checksums and -fno-strict-aliasing
Дата
Msg-id 15258.1535759998@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: pg_verify_checksums and -fno-strict-aliasing  (Michael Paquier <michael@paquier.xyz>)
Ответы Re: pg_verify_checksums and -fno-strict-aliasing  (Michael Paquier <michael@paquier.xyz>)
Re: pg_verify_checksums and -fno-strict-aliasing  (Fabien COELHO <coelho@cri.ensmp.fr>)
Список pgsql-hackers
Michael Paquier <michael@paquier.xyz> writes:
> On Fri, Aug 31, 2018 at 03:55:51PM -0400, Tom Lane wrote:
>> I also fixed a few places that were using the palloc solution, and
>> one that was actually doing hand-alignment of the pointer (ugh).
>> I didn't try to be thorough about getting rid of such pallocs,
>> just fix places that seemed likely to be performance-critical.

> Okay, for the memo replay_image_masked and master_image_masked
> in xlog.c could make use of the new structure.  SetWALSegSize in
> pg_standby.c and WriteEmptyXLOG in pg_resetwal.c, and pg_upgrade's
> file.c could also be patched.

I intentionally didn't change replay_image_masked/master_image_masked
to use statically-allocated buffers.  Since, AFAICS, those aren't
needed in most backend processes, they'd just be eating 16KB of
per-process data space to no purpose.

The others you mention could be changed, probably, but I didn't
bother as they didn't seem performance-critical.

>> +typedef union PGAlignedBuffer

> One complain I have is about the name of those structures.  Perhaps
> PGAlignedBlock and PGAlignedXlogBlock make more sense?

Don't have a strong preference, anybody else have an opinion?

(I also wondered whether to use "WAL" instead of "XLog" in that
struct name, but it seems like we've mostly stuck with "xlog"
in internal C names.)

            regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: buildfarm: could not read block 3 in file "base/16384/2662": read only 0 of 8192 bytes
Следующее
От: Andres Freund
Дата:
Сообщение: Re: buildfarm: could not read block 3 in file "base/16384/2662":read only 0 of 8192 bytes