On 2024-06-06 Th 04:15, Kyotaro Horiguchi wrote:
At Thu, 06 Jun 2024 16:45:00 +0900 (JST), Kyotaro Horiguchi
wrote in
I have been thinking about this since then. At first, I thought it
referred to FindFirstChangeNotification() and friends, and inotify on
Linux. However, I haven't found a
At Thu, 06 Jun 2024 17:15:15 +0900 (JST), Kyotaro Horiguchi
wrote in
> At Thu, 06 Jun 2024 16:45:00 +0900 (JST), Kyotaro Horiguchi
> wrote in
> > I have been thinking about this since then. At first, I thought it
> > referred to FindFirstChangeNotification() and friends, and inotify on
> >
At Thu, 06 Jun 2024 16:45:00 +0900 (JST), Kyotaro Horiguchi
wrote in
> I have been thinking about this since then. At first, I thought it
> referred to FindFirstChangeNotification() and friends, and inotify on
> Linux. However, I haven't found a way to simplify the specified code
> area using
At Tue, 4 Jun 2024 08:30:19 +0900, Michael Paquier wrote
in
> On Mon, Jan 15, 2024 at 01:34:46PM -0500, Robert Haas wrote:
> > This kind of change looks massively helpful to me. I don't know if it
> > is exactly right or not, but it would have been a big help to me when
> > writing my previous
On Mon, Jan 15, 2024 at 01:34:46PM -0500, Robert Haas wrote:
> This kind of change looks massively helpful to me. I don't know if it
> is exactly right or not, but it would have been a big help to me when
> writing my previous review, so +1 for some change of this general
> type.
During a live
On Thu, Jan 11, 2024 at 3:33 AM Kyotaro Horiguchi
wrote:
> Is it correct to understand that you are requesting changes as follows?
>
> --- a/src/bin/pg_ctl/pg_ctl.c
> +++ b/src/bin/pg_ctl/pg_ctl.c
> @@ -1995,11 +1995,14 @@ pgwin32_find_postmaster_pid(pid_t shell_pid)
> *
> *
Thanks for restarting this thread.
At Tue, 9 Jan 2024 09:40:23 +0900, Michael Paquier wrote
in
> On Fri, Jan 05, 2024 at 02:58:55PM -0500, Robert Haas wrote:
> > I'm not a Windows expert, but my guess is that 0001 is a very good
> > idea. I hope someone who is a Windows expert will comment on
Michael Paquier writes:
> I am wondering if we'd better backpatch all that, TBH.
Seems like a good idea to me.
regards, tom lane
On Tue, Jan 09, 2024 at 09:40:12PM -0500, Tom Lane wrote:
> No Windows expert here, but it does seem like the same argument
> applies.
Yeah, I've applied the same restriction for pg_regress to avoid
similar problems as we spawn a postgres process in this case. I've
tested it and it was not
Michael Paquier writes:
> I have now applied 0001 for pg_ctl.
> While reviewing that, I have also noticed spawn_process() in
> pg_regress.c that includes direct command invocations with cmd.exe /c.
> Could it make sense to append an extra /d for this case as well?
No Windows expert here, but it
On Tue, Jan 09, 2024 at 09:40:23AM +0900, Michael Paquier wrote:
> On Fri, Jan 05, 2024 at 02:58:55PM -0500, Robert Haas wrote:
> > I'm not a Windows expert, but my guess is that 0001 is a very good
> > idea. I hope someone who is a Windows expert will comment on that.
>
> I am +1 on 0001. It is
On Fri, Jan 05, 2024 at 02:58:55PM -0500, Robert Haas wrote:
> I'm not a Windows expert, but my guess is that 0001 is a very good
> idea. I hope someone who is a Windows expert will comment on that.
I am +1 on 0001. It is just something we've never anticipated when
these wrappers around cmd in
On Tue, Oct 24, 2023 at 4:28 AM Kyotaro Horiguchi
wrote:
> In the attached, fixed the existing two messages, and adjusted one
> message to display an error code, all in the consistent format.
Hi,
I'm not a Windows expert, but my guess is that 0001 is a very good
idea. I hope someone who is a
At Tue, 24 Oct 2023 07:37:22 +, "Hayato Kuroda (Fujitsu)"
wrote in
> Dear Horiguchi-san,
>
> Thanks for updates! I was quite not sure the Windows env, but I can post
> comments.
> (We need reviews by windows-friendly developers...)
Indeed, I haven't managed to successfully build using
Dear Horiguchi-san,
Thanks for updates! I was quite not sure the Windows env, but I can post
comments.
(We need reviews by windows-friendly developers...)
> Other error cases will fit to "shouldn't occur under normal
> conditions" errors.
Formatting of messages for write_stderr() seem
At Mon, 23 Oct 2023 08:57:19 +, "Hayato Kuroda (Fujitsu)"
wrote in
> > I agree with your suggestion. Ultimately, if there's a possibility
> > for this to be committed, the message will be consolidated to "could
> > not start server".
>
> Based on the suggestion, I tried to update the
Dear Horiguchi-san, Shlok,
>
> At Fri, 6 Oct 2023 12:28:32 +0530, Shlok Kyal wrote
> i> D:\project\pg_dev\bin>pg_ctl -D ../data -l data2.log start
> > pg_ctl: another server might be running; trying to start server anyway
> > waiting for server to startpg_ctl: launcher shell died
> >
> >
Thank you for testing this!
At Fri, 6 Oct 2023 12:28:32 +0530, Shlok Kyal wrote
i> D:\project\pg_dev\bin>pg_ctl -D ../data -l data2.log start
> pg_ctl: another server might be running; trying to start server anyway
> waiting for server to startpg_ctl: launcher shell died
>
> The output
On Fri, 6 Oct 2023 at 11:38, Hayato Kuroda (Fujitsu)
wrote:
>
> Dear Horiguchi-san,
>
> Thank you for making a patch! They can pass ci.
> I'm still not sure what should be, but I can respond a part.
>
> > Another issue is.. that I haven't been able to cause the false
> > positive of pg_ctl
Dear Horiguchi-san,
Thank you for making a patch! They can pass ci.
I'm still not sure what should be, but I can respond a part.
> Another issue is.. that I haven't been able to cause the false
> positive of pg_ctl start.. Do you have a concise reproducer of the
> issue?
I found a short sleep
At Wed, 20 Sep 2023 14:18:41 +0900 (JST), Kyotaro Horiguchi
wrote in
> I was able to see the trouble in the CI environment, but not
> locally. I'll delve deeper into this. Thanks you for bringing it to my
> attention.
I found two instances with multiple child processes.
# child-pid /
At Tue, 19 Sep 2023 13:48:55 +, "Hayato Kuroda (Fujitsu)"
wrote in
> Dear Horiguchi-san,
>
> > I added the thread to next CF entry, so let's see the how cfbot says.
>
> At least there are several compiler warnings. E.g.,
>
> * pgwin32_find_postmaster_pid() has "return;", but IIUC it
Dear Horiguchi-san,
> I added the thread to next CF entry, so let's see the how cfbot says.
At least there are several compiler warnings. E.g.,
* pgwin32_find_postmaster_pid() has "return;", but IIUC it should be "exit(1)"
* When DWORD is printed, "%lx" should be used.
* The variable "flags"
Dear Horiguchi-san,
I have tested your patch on my CI, but several test could not patch with error:
"pg_ctl: launcher shell executed multiple processes".
I added the thread to next CF entry, so let's see the how cfbot says.
[1]: https://commitfest.postgresql.org/45/4573/
Best Regards,
Hayato
At Fri, 8 Sep 2023 08:02:57 +, "Hayato Kuroda (Fujitsu)"
wrote in
> > > Ditching cmd.exe seems like a big hassle. So, on the flip side, I
> > > tried to identify the postmaster PID using the shell's PID, and it
> > > seem to work. The APIs used are avaiable from XP/2003 onwards.
>
>
Dear Hoiguchi-san,
Thank you for making the patch!
> It doesn't seem to work as expected. We still lose the relationship
> between the PID file and the launched postmaster.
Yes, I did not expect that the relationship can be kept.
Conceptually +1 for your approach.
> > Ditching cmd.exe seems
At Fri, 08 Sep 2023 14:17:16 +0900 (JST), Kyotaro Horiguchi
wrote in
> Ditching cmd.exe seems like a big hassle. So, on the flip side, I
> tried to identify the postmaster PID using the shell's PID, and it
> seem to work. The APIs used are avaiable from XP/2003 onwards.
Cleaned it up a bit.
At Thu, 7 Sep 2023 10:53:41 +, "Hayato Kuroda (Fujitsu)"
wrote in
> 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
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
On Thu, Sep 07, 2023 at 07:07:36AM +, Hayato Kuroda (Fujitsu) wrote:
> # Problem
>
> The "pg_ctl start" command returns 0 (succeeded) even if the cluster has
> already been started. This occurs on Windows environment, and when the command
> is executed just after postmaster starts.
Not
30 matches
Mail list logo
