Repository navigation
Tags: postgrespro/testgres
Tags
Support separate execution contexts for spawned nodes (#447) * Allow spawning nodes in a different execution context PostgresNode cloning currently always reuses the source node's OsOperations and PortManager. NodeBackup propagates that behavior to spawn_primary(), spawn_replica(), and PostgresNode.replicate(), which prevents a spawned node from running in another execution context. Add optional target_os_ops, target_host and target_port arguments and propagate them through the cloning and backup/replication path. When the target OsOperations differs, let PostgresNode select a PortManager for that context. Preserve the existing behavior when the new arguments are not specified. A physical backup contains the source node's listen_addresses setting, so override listen_addresses and port with the spawned node's values. Also remove the same-host assertion from source_walsender: master process inspection is already performed through the master's own OsOperations. Different source and target OsOperations are supported when both execution contexts can access the backup directory using the same path. * Run backups in the target execution context The target OsOperations was previously applied only when constructing the spawned PostgresNode. The backup itself was still created using the source node's OsOperations. This worked when source and target execution contexts shared a filesystem, such as Linux network namespaces, but did not support different filesystems or remote hosts. Allow NodeBackup to use an explicit OsOperations and make PostgresNode.replicate() create the backup directly in target_os_ops. This makes pg_basebackup, temporary directory creation, copytree and backup cleanup operate in the target execution context. Spawned nodes now inherit the backup's OsOperations. When cloning into a different OsOperations, do not inherit source bin_dir or host; let the target PostgresNode resolve them from its own execution context. Add tests for backup copying across execution contexts and physical replication from a remote source to a local target. * Test are updated (new asserts) * Add PgLab Linux fault-injection support PgLab keeps PostgreSQL lifecycle, backup and replication in Testgres while placing nodes into separate Linux network namespaces and cgroups. This provides a concrete consumer for the target execution-context replication API: replicas can use their own OsOperations, address and port while pg_basebackup runs in the target context. * Run PgLab integration tests in CI Add the PgLab regression suite to Testgres tests and run the privileged Linux scenarios in a dedicated Ubuntu job. The normal test matrix only runs the API compatibility checks. Destructive netns/cgroup tests are opt-in through TESTGRES_PGLAB_TESTS and are enabled by the dedicated CI job. * Fix PgLab flake8 issues * Fix PgLab flake8 issues * Revert "Fix PgLab flake8 issues" This reverts commit 2b4fbb1. * Revert "Fix PgLab flake8 issues" This reverts commit 901bced. * Revert "Run PgLab integration tests in CI" This reverts commit 29d8f98. * Revert "Add PgLab Linux fault-injection support" This reverts commit d5fb01d. --------- Co-authored-by: d.kovalenko <dmitry.lipetsk@gmail.com>
Migration to new os_ops methods: run and popen (#430) * node::psql/safe_psql use os_ops::run * node::_try_shutdown_internal uses os_ops::run * node::pgbench returns OsProcessController * node::upgrade_from uses os_ops::run * FindPostmaster uses os_ops::run * utils.get_pg_config2 uses os_ops::run * utils.get_pg_version2 uses os_ops::run
PreviousNext