Thread

1. BUG #18958: "pg_ctl start" allows subsequent CTRL-C key in cmd.exe to unexpectedly terminate cluster on Windows

   PG Bug reporting form <noreply@postgresql.org> — 2025-06-13T13:21:04Z

   The following bug has been logged on the website:
   
   Bug reference:      18958
   Logged by:          Seva Zaslavsky
   Email address:      szaslavsky@mpcapitallp.com
   PostgreSQL version: 17.5
   Operating system:   Windows Server 2019
   Description:        
   
   In the process of upgrading from PG 13.18 to PG 17.5, I see a dangerous
   interaction/relation/link between the cmd.exe window that was used to run
   "pg_ctl start" and the cluster that was started that allows subsequent
   CTRL-C keypress in cmd.exe to unexpectedly terminate the cluster.
   Very easy to replicate:
   (1) Start by installing the community windows build of Postgresl 17.5 from
   EDB https://www.enterprisedb.com/downloads/postgres-postgresql-downloads
   (2) Change the logging config in postgresql.conf as follows:
   log_destination = 'stderr'
   logging_collector = on
   log_directory = 'pg_log'
   log_filename = 'postgresql-%Y-%m-%d_%H%M%S.log'
   log_file_mode = 0640
   log_rotation_age = 1d
   log_min_messages = info
   log_min_duration_statement = 30000
   log_checkpoints = on
   log_connections = on
   log_disconnections = on
   log_line_prefix = '%m [%p] [%a] '
   (3) start a windows command line "cmd.exe" with administrator access
   (4) Use "pg_ctl start" to start the cluster.  The way I did it is shown in
   the "cmd.exe Input/Output" section below.  Now the cluster should be
   started.
   (5) Type the "exit" command and press "Enter" to close the cmd.exe window.
   After entering the "exit" command, the cmd.exe window should normally close
   and disappear but it just sits there.
   (6) Click on the "X" in the upper-right corner which should close the
   window.  When I click on the "X" in the upper right of cmd.exe and the
   window still does not close but it generates the output in the log starting
   at 2025-06-13 08:45:21.441 below.
   (7) Press CTRL-C with the cmd.exe window active.  Then I press "CTRL-C" with
   the cmd.exe window in focus, the cmd.exe window closes AND IT SHUTS DOWN THE
   CLUSTER with the log output starting at 2025-06-13 08:48:51.597 below.  I am
   surprised that pressing CTRL-C in a command window would affect a running
   cluster in any way.
   =========== cmd.exe Input/Output ==============
   Microsoft Windows [Version 10.0.17763.7136]
   (c) 2018 Microsoft Corporation. All rights reserved.
   J:\Users\Public\PostgreSQL\data>"c:\Program
   Files\PostgreSQL\17.5\bin\pg_ctl" start -D
   "J:\Users\Public\PostgreSQL\data\5438" -o "-p 5438"
   waiting for server to start....2025-06-13 08:44:06.019 EDT [10020] [] LOG:
   redirecting log output to logging collector process
   2025-06-13 08:44:06.019 EDT [10020] [] HINT:  Future log output will appear
   in directory "pg_log".
    done
   server started
   J:\Users\Public\PostgreSQL\data>exit
   =========== end cmd.exe Input/Output ==============
   =========== stderr-based log file ===============
   2025-06-13 08:44:06.019 EDT [10020] [] LOG:  starting PostgreSQL 17.5 on
   x86_64-windows, compiled by msvc-19.43.34808, 64-bit
   2025-06-13 08:44:06.021 EDT [10020] [] LOG:  listening on IPv6 address "::",
   port 5438
   2025-06-13 08:44:06.021 EDT [10020] [] LOG:  listening on IPv4 address
   "0.0.0.0", port 5438
   2025-06-13 08:44:06.084 EDT [6192] [] LOG:  database system was shut down at
   2025-06-11 15:03:46 EDT
   2025-06-13 08:44:06.134 EDT [10020] [] LOG:  could not reserve shared memory
   region (addr=000001C45CBB0000) for child 000000000000219C: error code 487
   2025-06-13 08:44:06.142 EDT [10020] [] LOG:  database system is ready to
   accept connections
   <after clicking on the "X" in the upper-right corner of cmd.exe>
   2025-06-13 08:45:21.441 EDT [10020] [] LOG:  background worker "logical
   replication launcher" (PID 24932) was terminated by exception 0xC000013A
   2025-06-13 08:45:21.441 EDT [10020] [] HINT:  See C include file
   "ntstatus.h" for a description of the hexadecimal value.
   2025-06-13 08:45:21.441 EDT [10020] [] LOG:  terminating any other active
   server processes
   2025-06-13 08:45:21.461 EDT [10020] [] LOG:  all server processes
   terminated; reinitializing
   2025-06-13 08:45:22.408 EDT [13752] [] LOG:  database system was
   interrupted; last known up at 2025-06-13 08:44:06 EDT
   2025-06-13 08:45:22.601 EDT [13752] [] LOG:  database system was not
   properly shut down; automatic recovery in progress
   2025-06-13 08:45:22.603 EDT [13752] [] LOG:  redo starts at 0/4B0000A0
   2025-06-13 08:45:22.603 EDT [13752] [] LOG:  invalid record length at
   0/4B0000D8: expected at least 24, got 0
   2025-06-13 08:45:22.603 EDT [13752] [] LOG:  redo done at 0/4B0000A0 system
   usage: CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s
   2025-06-13 08:45:22.606 EDT [27952] [] LOG:  checkpoint starting:
   end-of-recovery immediate wait
   2025-06-13 08:45:22.889 EDT [27952] [] LOG:  checkpoint complete: wrote 3
   buffers (0.0%); 0 WAL file(s) added, 0 removed, 0 recycled; write=0.280 s,
   sync=0.002 s, total=0.285 s; sync files=2, longest=0.001 s, average=0.001 s;
   distance=0 kB, estimate=0 kB; lsn=0/4B0000D8, redo lsn=0/4B0000D8
   2025-06-13 08:45:22.912 EDT [10020] [] LOG:  database system is ready to
   accept connections
   <pressing CTRL-C with the cmd.exe window being active>
   2025-06-13 08:48:51.597 EDT [18868] [] ERROR:  canceling statement due to
   user request
   2025-06-13 08:48:51.597 EDT [10144] [] ERROR:  canceling statement due to
   user request
   2025-06-13 08:48:51.598 EDT [10020] [] LOG:  received fast shutdown request
   2025-06-13 08:48:51.599 EDT [10020] [] LOG:  aborting any active
   transactions
   2025-06-13 08:48:51.605 EDT [10020] [] LOG:  background worker "logical
   replication launcher" (PID 18868) exited with exit code 1
   2025-06-13 08:48:51.626 EDT [27952] [] LOG:  shutting down
   2025-06-13 08:48:51.646 EDT [27952] [] LOG:  checkpoint starting: shutdown
   immediate
   2025-06-13 08:48:51.749 EDT [27952] [] LOG:  checkpoint complete: wrote 0
   buffers (0.0%); 0 WAL file(s) added, 0 removed, 1 recycled; write=0.100 s,
   sync=0.001 s, total=0.105 s; sync files=0, longest=0.000 s, average=0.000 s;
   distance=16383 kB, estimate=16383 kB; lsn=0/4C000028, redo lsn=0/4C000028
   2025-06-13 08:48:52.105 EDT [10020] [] LOG:  database system is shut down
   
   

2. Re: BUG #18958: "pg_ctl start" allows subsequent CTRL-C key in cmd.exe to unexpectedly terminate cluster on Windows

   David G. Johnston <david.g.johnston@gmail.com> — 2025-06-13T13:46:39Z

   On Fri, Jun 13, 2025 at 6:34 AM PG Bug reporting form <
   noreply@postgresql.org> wrote:
   
   > The following bug has been logged on the website:
   >
   > Bug reference:      18958
   > Logged by:          Seva Zaslavsky
   > Email address:      szaslavsky@mpcapitallp.com
   > PostgreSQL version: 17.5
   > Operating system:   Windows Server 2019
   > Description:
   >
   > J:\Users\Public\PostgreSQL\data>"c:\Program
   > Files\PostgreSQL\17.5\bin\pg_ctl" start -D
   > "J:\Users\Public\PostgreSQL\data\5438" -o "-p 5438"
   > waiting for server to start....2025-06-13 08:44:06.019 EDT [10020] [] LOG:
   > redirecting log output to logging collector process
   > 2025-06-13 08:44:06.019 EDT [10020] [] HINT:  Future log output will appear
   > in directory "pg_log".
   >  done
   > server started
   >
   >
   A bit surprising I suppose, but documented.
   
   """
   start mode launches a new server. The server is started in the background,
   and its standard input is attached to /dev/null (or nul on Windows). On
   Unix-like systems, by default, the server's standard output and standard
   error are sent to pg_ctl's standard output (not standard error). The
   standard output of pg_ctl should then be redirected to a file or piped to
   another process such as a log rotating program like rotatelogs; otherwise
   postgres will write its output to the controlling terminal (from the
   background) and will not leave the shell's process group. On Windows, by
   default the server's standard output and standard error are sent to the
   terminal. These default behaviors can be changed by using -l to append the
   server's output to a log file. Use of either -l or output redirection is
   recommended.
   """
   
   Note the final sentence, neither of which was done here.
   
   In short, while the server configuration stopped sending log data to
   stdout/stderr due to the log_collector directive pg_ctl has no awareness of
   that happening and so keeps itself attached to the process that launched it
   so the operator can see those streams.
   
   David J.
   

3. Re: BUG #18958: "pg_ctl start" allows subsequent CTRL-C key in cmd.exe to unexpectedly terminate cluster on Windows

   Seva Zaslavsky <szaslavsky@mpcapitallp.com> — 2025-06-13T14:51:14Z

   Using the -l flag with "pg_ctl start"  resolves this issue.  This was a 
   significant behavior change since PG 13.18.
   
   David - Thank you for the quick response.  Would appreciate if you have 
   any thoughts on another logging bug (or behavior change since PG 13.18) 
   that I documented on June 11 in #18955.
   
   On 6/13/2025 9:46 AM, David G. Johnston wrote:
   > On Fri, Jun 13, 2025 at 6:34 AM PG Bug reporting form 
   > <noreply@postgresql.org> wrote:
   >
   >     The following bug has been logged on the website:
   >
   >     Bug reference:      18958
   >     Logged by:          Seva Zaslavsky
   >     Email address: szaslavsky@mpcapitallp.com
   >     PostgreSQL version: 17.5
   >     Operating system:   Windows Server 2019
   >     Description:
   >
   >     J:\Users\Public\PostgreSQL\data>"c:\Program
   >     Files\PostgreSQL\17.5\bin\pg_ctl" start -D
   >     "J:\Users\Public\PostgreSQL\data\5438" -o "-p 5438"
   >     waiting for server to start....2025-06-13 08:44:06.019 EDT [10020]
   >     [] LOG:
   >     redirecting log output to logging collector process
   >     2025-06-13 08:44:06.019 EDT [10020] [] HINT:  Future log output
   >     will appear
   >     in directory "pg_log".
   >      done
   >     server started
   >
   >
   > A bit surprising I suppose, but documented.
   >
   > """
   > start mode launches a new server. The server is started in the 
   > background, and its standard input is attached to /dev/null (or nul on 
   > Windows). On Unix-like systems, by default, the server's standard 
   > output and standard error are sent to pg_ctl's standard output (not 
   > standard error). The standard output of pg_ctl should then be 
   > redirected to a file or piped to another process such as a log 
   > rotating program like rotatelogs; otherwise postgres will write its 
   > output to the controlling terminal (from the background) and will not 
   > leave the shell's process group. On Windows, by default the server's 
   > standard output and standard error are sent to the terminal. These 
   > default behaviors can be changed by using -l to append the server's 
   > output to a log file. Use of either -l or output redirection is 
   > recommended.
   > """
   >
   > Note the final sentence, neither of which was done here.
   >
   > In short, while the server configuration stopped sending log data to 
   > stdout/stderr due to the log_collector directive pg_ctl has no 
   > awareness of that happening and so keeps itself attached to the 
   > process that launched it so the operator can see those streams.
   >
   > David J.
   >

4. Re: BUG #18958: "pg_ctl start" allows subsequent CTRL-C key in cmd.exe to unexpectedly terminate cluster on Windows

   David G. Johnston <david.g.johnston@gmail.com> — 2025-06-13T14:58:05Z

   On Fri, Jun 13, 2025 at 7:51 AM Seva Zaslavsky <szaslavsky@mpcapitallp.com>
   wrote:
   
   > Using the -l flag with "pg_ctl start"  resolves this issue.  This was a
   > significant behavior change since PG 13.18.
   >
   
   I don't recall this changing recently...the documentation hasn't at least...
   
   David - Thank you for the quick response.  Would appreciate if you have any
   > thoughts on another logging bug (or behavior change since PG 13.18) that I
   > documented on June 11 in #18955.
   >
   That seems Windows OS specific which I'm unable to review and comment upon.
   
   David J.
   

5. Re: BUG #18958: "pg_ctl start" allows subsequent CTRL-C key in cmd.exe to unexpectedly terminate cluster on Windows

   Seva Zaslavsky <szaslavsky@mpcapitallp.com> — 2025-06-13T19:50:11Z

   All of the behavior I've described in the original bug post regarding 
   CTRL-C terminating the cluster is present in 13.18 - hence contrary to 
   what I asserted earlier, there is no "significant behavior change since 
   PG 13.18."
   
   However, the pg_ctl start "--log=filename" option only affects stdout 
   and stderr.
   
   I'm still observing the behavior that pressing CTRL-C inside cmd.exe 
   terminates the cluster that was started inside that cmd.exe.
   
   According to the documentation for pg_ctl "The server is started in the 
   background, and its standard input is attached to |/dev/null| (or |nul| 
   on Windows)." but if pressing CTRL-C in a cmd.exe window terminates the 
   cluster that was started inside that cmd.exe window, doesn't it seem 
   like stdin is attached to the output cmd.exe and not to NUL?
   
   Is it the expected behavior that pressing CTRL-C will terminate the 
   cluster that was started inside that cmd.exe on windows?
   
   On 6/13/2025 10:58 AM, David G. Johnston wrote:
   > On Fri, Jun 13, 2025 at 7:51 AM Seva Zaslavsky 
   > <szaslavsky@mpcapitallp.com> wrote:
   >
   >     Using the -l flag with "pg_ctl start"  resolves this issue.  This
   >     was a significant behavior change since PG 13.18.
   >
   >
   > I don't recall this changing recently...the documentation hasn't at 
   > least...
   >
   >     David - Thank you for the quick response.  Would appreciate if you
   >     have any thoughts on another logging bug (or behavior change since
   >     PG 13.18) that I documented on June 11 in #18955.
   >
   > That seems Windows OS specific which I'm unable to review and comment 
   > upon.
   >
   > David J.
   >

6. Re: BUG #18958: "pg_ctl start" allows subsequent CTRL-C key in cmd.exe to unexpectedly terminate cluster on Windows

   David G. Johnston <david.g.johnston@gmail.com> — 2025-06-13T20:04:38Z

   On Fri, Jun 13, 2025 at 12:50 PM Seva Zaslavsky <szaslavsky@mpcapitallp.com>
   wrote:
   
   > I'm still observing the behavior that pressing CTRL-C inside cmd.exe
   > terminates the cluster that was started inside that cmd.exe.
   >
   > According to the documentation for pg_ctl "The server is started in the
   > background, and its standard input is attached to /dev/null (or nul on
   > Windows)." but if pressing CTRL-C in a cmd.exe window terminates the
   > cluster that was started inside that cmd.exe window, doesn't it seem like
   > stdin is attached to the output cmd.exe and not to NUL?
   >
   ctrl-c sends an operating system signal.  Signals don't use
   stdin/stdout/etc... to communicate
   
   David J.