pgsql: Add prefix checks in exclude lists for pg_rewind, pg_checksums a

Add prefix checks in exclude lists for pg_rewind, pg_checksums and base backups An instance of PostgreSQL crashing with a bad timing could leave behind temporary pg_internal.init files, potentially causing failures when verifying checksums. As the same exclusion lists are used between pg_rewind,

pgsql: Add prefix checks in exclude lists for pg_rewind, pg_checksums a

Add prefix checks in exclude lists for pg_rewind, pg_checksums and base backups An instance of PostgreSQL crashing with a bad timing could leave behind temporary pg_internal.init files, potentially causing failures when verifying checksums. As the same exclusion lists are used between pg_rewind,

pgsql: Add prefix checks in exclude lists for pg_rewind, pg_checksums a

Add prefix checks in exclude lists for pg_rewind, pg_checksums and base backups An instance of PostgreSQL crashing with a bad timing could leave behind temporary pg_internal.init files, potentially causing failures when verifying checksums. As the same exclusion lists are used between pg_rewind,

pgsql: Move bitmap_hash and bitmap_match to bitmapset.c.

Move bitmap_hash and bitmap_match to bitmapset.c. The closely-related function bms_hash_value is already defined in that file, and this change means that hashfn.c no longer needs to depend on nodes/bitmapset.h. That gets us closer to allowing use of the hash functions in hashfn.c in frontend code.

pgsql: Put all the prototypes for hashfn.c into the same header file.

Put all the prototypes for hashfn.c into the same header file. Previously, some of the prototypes for functions in hashfn.c were in utils/hashutils.h and others were in utils/hsearch.h, but that is confusing and has no particular benefit. Patch by me, reviewed by Suraj Kharage and Mark Dilger. D

pgsql: Adapt hashfn.c and hashutils.h for frontend use.

Adapt hashfn.c and hashutils.h for frontend use. hash_any() and its various variants are defined to return Datum, which is a backend-only concept, but the underlying functions actually want to return uint32 and uint64, and only return Datum because it's convenient for callers who are using them to

pgsql: Change client-side fsync_fname() to report errors fatally

Change client-side fsync_fname() to report errors fatally Given all we have learned about fsync() error handling in the last few years, reporting an fsync() error non-fatally is not useful, unless you don't care much about the file, in which case you probably don't need to use fsync() in the first

pgsql: Account explicitly for long-lived FDs that are allocated outside

Account explicitly for long-lived FDs that are allocated outside fd.c. The comments in fd.c have long claimed that all file allocations should go through that module, but in reality that's not always practical. fd.c doesn't supply APIs for invoking some FD-producing syscalls like pipe() or epoll_c

pgsql: Issue properly WAL record for CID of first catalog tuple in mult

Issue properly WAL record for CID of first catalog tuple in multi-insert Multi-insert for heap is not yet used actively for catalogs, but the code to support this case is in place for logical decoding. The existing code forgot to issue a XLOG_HEAP2_NEW_CID record for the first tuple inserted, lea

pgsql: expression eval: Reduce number of steps for agg transition invoc

expression eval: Reduce number of steps for agg transition invocations. Do so by combining the various steps that are part of aggregate transition function invocation into one larger step. As some of the current steps are only necessary for some aggregates, have one variant of the aggregate transi

pgsql: Fix compile failure.

Fix compile failure. I forgot that some compilers won't handle #if constructs within ereport() calls. Duplicating most of the call is annoying but simple. Per buildfarm. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/36390713a60f446da7e7ae758771c9104fa89394 Modif

pgsql: Fix build failure on header generation with repetitive builds of

Fix build failure on header generation with repetitive builds of MSVC GenerateConfigHeader() in Solution.pm was complaining about unused define symbols even if a newer config header was not generated, causing successive build attempts with MSVC to fail. Oversight in commit 8f4fb4c. Author: Kyota