mirror of
https://git.postgresql.org/git/postgresql.git
synced 2026-02-17 20:07:00 +08:00
bebb281b08
PostgreSQL's src/port/open.c has always set bInheritHandle = TRUE when opening files on Windows, making all file descriptors inheritable by child processes. This meant the O_CLOEXEC flag, added to many call sites by commit 1da569ca1f (v16), was silently ignored. The original commit included a comment suggesting that our open() replacement doesn't create inheritable handles, but it was a mis- understanding of the code path. In practice, the code was creating inheritable handles in all cases. This hasn't caused widespread problems because most child processes (archive_command, COPY PROGRAM, etc.) operate on file paths passed as arguments rather than inherited file descriptors. Even if a child wanted to use an inherited handle, it would need to learn the numeric handle value, which isn't passed through our IPC mechanisms. Nonetheless, the current behavior is wrong. It violates documented O_CLOEXEC semantics, contradicts our own code comments, and makes PostgreSQL behave differently on Windows than on Unix. It also creates potential issues with future code or security auditing tools. To fix, define O_CLOEXEC to _O_NOINHERIT in master, previously used by O_DSYNC. We use different values in the back branches to preserve existing values. In pgwin32_open_handle() we set bInheritHandle according to whether O_CLOEXEC is specified, for the same atomic semantics as POSIX in multi-threaded programs that create processes. Backpatch-through: 16 Author: Bryan Green <dbryan.green@gmail.com> Co-authored-by: Thomas Munro <thomas.munro@gmail.com> (minor adjustments) Discussion: https://postgr.es/m/e2b16375-7430-4053-bda3-5d2194ff1880%40gmail.com
Test extensions and libraries ============================= src/test/modules contains PostgreSQL extensions that are primarily or entirely intended for testing PostgreSQL and/or to serve as example code. The extensions here aren't intended to be installed in a production server and aren't suitable for "real work". Furthermore, while you can do "make install" and "make installcheck" in this directory or its children, it is NOT ADVISABLE to do so with a server containing valuable data. Some of these tests may have undesirable side-effects on roles or other global objects within the tested server. "make installcheck-world" at the top level does not recurse into this directory. Most extensions have their own pg_regress tests or isolationtester specs. Some are also used by tests elsewhere in the tree. If you're adding new hooks or other functionality exposed as C-level API this is where to add the tests for it.