pgsql: Add macro to disable address safety instrumentation

Add macro to disable address safety instrumentation fasthash_accum_cstring_aligned() uses a technique, found in various strlen() implementations, to detect a string's NUL terminator by reading a word at at time. That triggers failures when testing with "-fsanitize=address", at least with frontend

pgsql: Fix incorrect return type

Fix incorrect return type fasthash32() calculates a 32-bit hashcode, but the return type was uint64. Change to uint32. Noted by Jeff Davis Discussion: https://postgr.es/m/b16c93e6c736a422d4de668343515375664eb05d.camel%40j-davis.com Branch -- master Details --- https://git.postgresql.o

pgsql: Convert uses of hash_string_pointer to fasthash equivalent

Convert uses of hash_string_pointer to fasthash equivalent Remove duplicate hash_string_pointer() function definitions by creating a new inline function hash_string() for this purpose. This has the added advantage of avoiding strlen() calls when doing hash lookup. It's not clear how many of these

pgsql: Improve read_stream.c's fast path.

Improve read_stream.c's fast path. The "fast path" for well cached scans that don't do any I/O was accidentally coded in a way that could only be triggered by pg_prewarm's usage pattern, which starts out with a higher distance because of the flags it passes in. We want it to work for streaming se

pgsql: Fix headerscheck violation introduced in f8ce4ed78ca

Fix headerscheck violation introduced in f8ce4ed78ca Per ci. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/9e7386924e837aef8d48895cf72a6a0b7f78cbe9 Modified Files -- src/bin/pg_combinebackup/reconstruct.h | 1 + 1 file changed, 1 insertion(+)

pgsql: Silence some compiler warnings in commit 3311ea86ed

Silence some compiler warnings in commit 3311ea86ed Per report from Nathan Bossart Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/c3e60f3d7e4268c6448ec592053b3b893899867d Modified Files -- src/common/jsonapi.c | 7 +++ 1 file changed, 7 insertions(+

pgsql: Fix incorrect calculation in BlockRefTableEntryGetBlocks.

Fix incorrect calculation in BlockRefTableEntryGetBlocks. The previous formula was incorrect in the case where the function's nblocks argument was a multiple of BLOCKS_PER_CHUNK, which happens whenever a relation segment file is exactly 512MB or exactly 1GB in length. In such cases, the formula wo

pgsql: Check HAVE_COPY_FILE_RANGE before calling copy_file_range

Check HAVE_COPY_FILE_RANGE before calling copy_file_range Fix a mistake in ac8110155132 - write_reconstructed_file() called copy_file_range() without properly checking HAVE_COPY_FILE_RANGE. Reported by several macOS machines. Also reported by cfbot, but I missed that issue before commit. Branch

pgsql: Allow using copy_file_range in write_reconstructed_file

Allow using copy_file_range in write_reconstructed_file This commit allows using copy_file_range() for efficient combining of data from multiple files, instead of simply reading/writing the blocks. Depending on the filesystem and other factors (size of the increment, distribution of modified block

pgsql: Make libpqsrv_cancel's return const char *, not char *

Make libpqsrv_cancel's return const char *, not char * Per headerscheck's C++ check. Discussion: https://postgr.es/m/372769.1712179...@sss.pgh.pa.us Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/b8b37e41ba4aae1e79dcfaeb9eb0fd7549773ff5 Modified Files ---

pgsql: Remove unused variable in checksum_file()

Remove unused variable in checksum_file() The 'offset' variable was set but otherwise unused. Per buildfarm animals with clang, e.g. sifaka and longlin. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/8e392595e5619734db707553e8f72dfacf9ab86c Modified Files ---

pgsql: Allow copying files using clone/copy_file_range

Allow copying files using clone/copy_file_range Adds --clone/--copy-file-range options to pg_combinebackup, to allow copying files using file cloning or copy_file_range(). These methods may be faster than the standard block-by-block copy, but the main advantage is that they enable various features

pgsql: Suppress "variable may be used uninitialized" warning.

Suppress "variable may be used uninitialized" warning. Buildfarm member caiman is showing this, which surprises me because it's very late-model gcc (14.0.1) and ought to be smart enough to know that elog(ERROR) doesn't return. But we're likely to see the same from stupider compilers too, so add a

pgsql: docs: Merge separate chapters on built-in index AMs into one.

docs: Merge separate chapters on built-in index AMs into one. The documentation index is getting very long, which makes it hard to find things. Since these chapters are all very similar in structure and content, merging them is a natural way of reducing the size of the toplevel index. Rather than

pgsql: Align blocks in incremental backups to BLCKSZ

Align blocks in incremental backups to BLCKSZ Align blocks stored in incremental files to BLCKSZ, so that the incremental backups work well with CoW filesystems. The header of the incremental file is padded with \0 to a multiple of BLCKSZ, so that the block data (also BLCKSZ) is aligned to BLCKSZ

pgsql: Operate XLogCtl->log{Write,Flush}Result with atomics

Operate XLogCtl->log{Write,Flush}Result with atomics This removes the need to hold both the info_lck spinlock and WALWriteLock to update them. We use stock atomic write instead, with WALWriteLock held. Readers can use atomic read, without any locking. This allows for some code to be reordered: