Fix off-by-one in XLogRecordMaxSize check.
pg_logical_emit_message(false, '_', repeat('x', 1069547465)) failed with
self-contradictory message "WAL record would be 1069547520 bytes (of
maximum 1069547520 bytes)". There's no particular benefit from allowing
or denying one byte in either direction;
Fix off-by-one in XLogRecordMaxSize check.
pg_logical_emit_message(false, '_', repeat('x', 1069547465)) failed with
self-contradictory message "WAL record would be 1069547520 bytes (of
maximum 1069547520 bytes)". There's no particular benefit from allowing
or denying one byte in either direction;
ci: macos: Remove use of -DRANDOMIZE_ALLOCATED_MEMORY
RANDOMIZE_ALLOCATED_MEMORY causes a measurable slowdown. Macos is, by far, the
most expensive platform for CI, therefore it doesn't make sense to run such a
test there.
Ubsan and asan on linux should detect most of the the cases of uninitializ
ci: macos: Remove use of -DRANDOMIZE_ALLOCATED_MEMORY
RANDOMIZE_ALLOCATED_MEMORY causes a measurable slowdown. Macos is, by far, the
most expensive platform for CI, therefore it doesn't make sense to run such a
test there.
Ubsan and asan on linux should detect most of the the cases of uninitializ
ci: macos: Remove use of -Dsegsize_blocks=6
The option causes a measurable slowdown. Macos is, by far, the most expensive
platform for CI, therefore it doesn't make sense to run such a test there.
d3b111e3205 used a small segment size for two tasks, one with autoconf, one
with meson. In hindsight
ci: macos: Remove use of -Dsegsize_blocks=6
The option causes a measurable slowdown. Macos is, by far, the most expensive
platform for CI, therefore it doesn't make sense to run such a test there.
d3b111e3205 used a small segment size for two tasks, one with autoconf, one
with meson. In hindsight
