Horton

RE: pg_ctl start may return 0 even if the postmaster has been already started on Windows

Hayato Kuroda (Fujitsu) <kuroda.hayato@fujitsu.com>

View thread View on postgr.es
From: "Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>
To: 'Michael Paquier' <michael@paquier.xyz>
Cc: 'PostgreSQL Hackers' <pgsql-hackers@lists.postgresql.org>
Date: 2023-09-07T10:53:41Z
Lists: pgsql-hackers

Attachments

Dear Michael,

Thank you for replying!

> Not failing on `pg_ctl start` if the command is run on a data folder
> that has already been started previously by a different command with a
> postmaster still alive feels like cheating, because pg_ctl is lying
> about its result.  If pg_ctl wants to start a cluster but is not able
> to do it, either because the postmaster failed at startup or because
> the cluster has already started, it should report a failure.

I have a same feelings as you. Users may use the return code in their batch file
and they may decide what to do based on the wrong status. Reporting the status
more accurately is nice.

My first idea is that to move the checking part to above, but this may not handle
the case the postmaster is still alive (now sure this is real issue). Do we have to
add a new indicator which ensures the identity of processes for windows?
Please tell me how you feel.

> Now, I
> also recall that the processes spawned by pg_ctl on Windows make the
> status handling rather tricky to reason about..

Did you say about the below comment? Currently I have no idea to make
codes more proper, sorry.

```
		 * On Windows, we may be checking the postmaster's parent shell, but
		 * that's fine for this purpose.
```

Best Regards,
Hayato Kuroda
FUJITSU LIMITED

Commits

  1. Re-enable autoruns for cmd.exe on Windows

  2. Re-enable autoruns for for cmd.exe on Windows

  3. pg_regress: Disable autoruns for cmd.exe on Windows

  4. pg_ctl: Disable autoruns for cmd.exe on Windows