pg.ddx.io pgsql-bugs@postgresql.org mailing list archive
help / color / mirror / Atom feedBUG #18958: "pg_ctl start" allows subsequent CTRL-C key in cmd.exe to unexpectedly terminate cluster on Windows
6+ messages / 3 participants
[nested] [flat]
* BUG #18958: "pg_ctl start" allows subsequent CTRL-C key in cmd.exe to unexpectedly terminate cluster on Windows
@ 2025-06-13 13:21 PG Bug reporting form <noreply@postgresql.org>
0 siblings, 1 reply; 6+ messages in thread
From: PG Bug reporting form @ 2025-06-13 13:21 UTC (permalink / raw)
To: pgsql-bugs@lists.postgresql.org; +Cc: szaslavsky@mpcapitallp.com
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
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: BUG #18958: "pg_ctl start" allows subsequent CTRL-C key in cmd.exe to unexpectedly terminate cluster on Windows
@ 2025-06-13 13:46 David G. Johnston <david.g.johnston@gmail.com>
parent: PG Bug reporting form <noreply@postgresql.org>
0 siblings, 1 reply; 6+ messages in thread
From: David G. Johnston @ 2025-06-13 13:46 UTC (permalink / raw)
To: szaslavsky@mpcapitallp.com; pgsql-bugs@lists.postgresql.org
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.
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: BUG #18958: "pg_ctl start" allows subsequent CTRL-C key in cmd.exe to unexpectedly terminate cluster on Windows
@ 2025-06-13 14:51 Seva Zaslavsky <szaslavsky@mpcapitallp.com>
parent: David G. Johnston <david.g.johnston@gmail.com>
0 siblings, 1 reply; 6+ messages in thread
From: Seva Zaslavsky @ 2025-06-13 14:51 UTC (permalink / raw)
To: David G. Johnston <david.g.johnston@gmail.com>; pgsql-bugs@lists.postgresql.org
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.
>
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: BUG #18958: "pg_ctl start" allows subsequent CTRL-C key in cmd.exe to unexpectedly terminate cluster on Windows
@ 2025-06-13 14:58 David G. Johnston <david.g.johnston@gmail.com>
parent: Seva Zaslavsky <szaslavsky@mpcapitallp.com>
0 siblings, 1 reply; 6+ messages in thread
From: David G. Johnston @ 2025-06-13 14:58 UTC (permalink / raw)
To: Seva Zaslavsky <szaslavsky@mpcapitallp.com>; +Cc: pgsql-bugs@lists.postgresql.org
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.
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: BUG #18958: "pg_ctl start" allows subsequent CTRL-C key in cmd.exe to unexpectedly terminate cluster on Windows
@ 2025-06-13 19:50 Seva Zaslavsky <szaslavsky@mpcapitallp.com>
parent: David G. Johnston <david.g.johnston@gmail.com>
0 siblings, 1 reply; 6+ messages in thread
From: Seva Zaslavsky @ 2025-06-13 19:50 UTC (permalink / raw)
To: David G. Johnston <david.g.johnston@gmail.com>; +Cc: pgsql-bugs@lists.postgresql.org
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.
>
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: BUG #18958: "pg_ctl start" allows subsequent CTRL-C key in cmd.exe to unexpectedly terminate cluster on Windows
@ 2025-06-13 20:04 David G. Johnston <david.g.johnston@gmail.com>
parent: Seva Zaslavsky <szaslavsky@mpcapitallp.com>
0 siblings, 0 replies; 6+ messages in thread
From: David G. Johnston @ 2025-06-13 20:04 UTC (permalink / raw)
To: Seva Zaslavsky <szaslavsky@mpcapitallp.com>; +Cc: pgsql-bugs@lists.postgresql.org
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.
^ permalink raw reply [nested|flat] 6+ messages in thread
end of thread, other threads:[~2025-06-13 20:04 UTC | newest]
Thread overview: 6+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2025-06-13 13:21 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-13 13:46 ` David G. Johnston <david.g.johnston@gmail.com>
2025-06-13 14:51 ` Seva Zaslavsky <szaslavsky@mpcapitallp.com>
2025-06-13 14:58 ` David G. Johnston <david.g.johnston@gmail.com>
2025-06-13 19:50 ` Seva Zaslavsky <szaslavsky@mpcapitallp.com>
2025-06-13 20:04 ` David G. Johnston <david.g.johnston@gmail.com>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox