Re: PostgreSQL Service on Windows does not start. ~ "is not a valid Win32 application"

From: Rajeev rastogi <rajeev(dot)rastogi(at)huawei(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Naoya Anzai <anzai-naoya(at)mxu(dot)nes(dot)nec(dot)co(dot)jp>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: PostgreSQL Service on Windows does not start. ~ "is not a valid Win32 application"
Date: 2013-11-26 12:09:31
Message-ID: BF2827DCCE55594C8D7A8F7FFD3AB7713DDAE329@SZXEML508-MBX.china.huawei.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 25 November 2013, Rajeev Rastogi Wrote:
> > > One suggestion:
> > > Instead of using sizeof(cmdLine),
> > > a. Can't we use strlen (hence small 'for' loop).
> > > b. Or use memmove to move one byte.
> >
> > I looked at this patch a bit. I agree that we need to fix
> > pgwin32_CommandLine to double-quote the executable name, but it needs
> > a great deal more work than that :-(. Whoever wrote this code was
> > apparently unacquainted with the concept of buffer overrun. It's not
> > going to be hard at all to crash pg_ctl with overlength arguments.
> > I'm not sure that that amounts to a security bug, but it's certainly
> bad.
> >
> > After some thought it seems like the most future-proof fix is to not
> > use a fixed-length buffer for the command string at all. The
> attached
> > revised patch switches it over to using a PQExpBuffer instead, which
> > is pretty much free since we're relying on libpq anyway in this
> program.
> > (We still use a fixed-length buffer for the program path, which is OK
> > because that's what find_my_exec and find_other_exec expect.)
> >
> > In addition, I fixed it to append .exe in both cases not just the one.
> >
> > I'm not in a position to actually test this, but it does compile
> > without warnings.
>
> I tested the latest patch. My observation is:
> If we give relative data directory path while registering the
> service, then service start fails.
> But same works if the data directory is absolute path.
>
> Looks like an existing issue. May be we need to internally
> convert relative data path to absolute.

Since the mentioned issue is an existing issue and not because of this patch.
So can we take that as separate defect and fix. If so, then I can
move this patch to "ready for committer".

Thanks and Regards,
Kumar Rajeev Rastogi

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2013-11-26 12:12:21 Re: ToDo: fast update of arrays with fixed length fields for PL/pgSQL
Previous Message Pavel Stehule 2013-11-26 12:08:28 Re: ToDo: fast update of arrays with fixed length fields for PL/pgSQL