Make password history replication-aware via a custom WAL-rmgr

[Giperboloid]

Problem --
The password history file is credcheck's persistent record of previously used password hashes. Before this patch, every write to it was a direct local file operation with no WAL coverage. Standbys never received those changes — meaning that in any streaming-replication setup, the password history was silently inconsistent between the primary and its replicas. After a failover, the promoted standby would enforce a completely different (or empty) password history, undermining the entire point of the password_reuse_history / password_reuse_interval policy.

Approach --
PostgreSQL 15 introduced the Custom WAL Resource Manager API (RegisterCustomRmgr), which allows extensions to plug into the WAL machinery with their own record types and redo routines. This patch uses that API to emit a WAL record for every mutation of the in-memory password history hash, so that standbys can replay those mutations and stay in sync.

The feature is compiled only on PG ≥ 15 and is entirely gated by #if PG_VERSION_NUM >= 150000. On older versions the code builds and behaves exactly as before.

Implementation details --
A new resource manager credcheck_rmgr is registered under RM_EXPERIMENTAL_ID — a stable ID will be requested from the PostgreSQL project when the patch matures. It exposes the three required callbacks: credcheck_rmgr_redo for replaying records during recovery, credcheck_rmgr_desc for producing human-readable descriptions for pg_waldump, and credcheck_rmgr_identify for mapping opcodes to symbolic names.

Six WAL record types cover every operation that mutates the history. XLOG_CREDCHECK_PWD_ADD is emitted when a new password hash is appended on CREATE/ALTER ROLE ... PASSWORD. XLOG_CREDCHECK_PWD_REMOVE fires when the oldest entry is evicted to stay within the history limit. XLOG_CREDCHECK_PWD_REMOVE_USER covers DROP ROLE, removing all entries for a given role at once. XLOG_CREDCHECK_PWD_RENAME handles ALTER ROLE ... RENAME TO. XLOG_CREDCHECK_PWD_RESET is written when history is truncated via pg_password_history_reset(), optionally scoped to one user. Finally, XLOG_CREDCHECK_PWD_TIMESTAMP is emitted when a password date is updated during password_reuse_interval enforcement.

RESET and TIMESTAMP records are immediately followed by XLogFlush() to ensure the standby has received them before the originating transaction is considered complete. The remaining record types rely on normal WAL flushing behavior, which is sufficient for history consistency.

credcheck_rmgr_redo() mirrors the primary's in-memory hash operations: it inserts, removes, renames, or resets entries in pgph_hash and then calls the existing pgph_write() helper to persist the result to history file on the standby's data directory.

One operational requirement: credcheck must be listed in shared_preload_libraries on the standby so that RegisterCustomRmgr() is called before recovery begins reading WAL records with RM_CREDCHECK_ID. This is the standard requirement for any extension using Custom WAL RMgrs

This patch introduces replication support only. The underlying extension logic still does not provide transactional behavior for password history writes.

Testing --
A new TAP 001_history_replication.pl tests the full end-to-end replication path. It sets up a primary and streaming standby pair with credcheck preloaded on both, then verifies that credcheck appears in pg_get_wal_resource_managers() on both nodes. It creates roles, generates several password changes, and confirms the standby's pg_password_history view matches the primary after wait_for_catchup. Each operation type is tested individually: rename, drop, and explicit reset. The standby is then restarted to verify that history file written during redo is correctly reloaded from disk. Finally the standby is promoted, and the test confirms that the replicated history survives promotion: a reused password is rejected and a fresh one is accepted.

[Giperboloid]

Hi!

I'd be glad to get any thoughts about the patch.

Regards

[Giperboloid]

Hi!
I've updated my branch by adding two minor fixes on issues highlighted in CI:

1. const qualifier has been removed from credcheck_rmgr struct definition
2. tap-test's directory t has been moved to project's root due to pgxs rules

It seems that there should not be problems in CI now.

[darold]

Hi Aidar,

Yes I have already found that the t/ directory must be on top of the project and review the patch. I have also tested on PG version from 16 to 18. It is an excellent work, thanks you very much! Your help is much appreciated. I'm applying the PR, the installcheck works well on my computer too but I think that the CI file might need to be fixed with the TAP test but your patch works as expected. I will have a look today.

Thanks again!