> >Is there any reason to worry about an accidental environment
> conflict?
> >If someone mistakenly did "export PG_RESTRICT_EXEC=1", it
> looks to me
> >like this would cause the re-exec bit to be skipped, but I
> suppose the
> >worst possible consequence is that the postmaster would
> refus
> > Thinking about this a tiny bit more, it struck me that by
> far the best
> > way to do this is to stop using a magic argument and use the
> > environment instead. Then we don't need to mangle the
> command line at
> > all. This actually results in less code, and should be more robust
> >
Tom Lane wrote:
Is there any reason to worry about an accidental environment conflict?
If someone mistakenly did "export PG_RESTRICT_EXEC=1", it looks to me
like this would cause the re-exec bit to be skipped, but I suppose the
worst possible consequence is that the postmaster would refuse to s
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Thinking about this a tiny bit more, it struck me that by far the best
> way to do this is to stop using a magic argument and use the environment
> instead. Then we don't need to mangle the command line at all. This
> actually results in less code, an
Andrew Dunstan wrote:
Magnus Hagander wrote:
The solution would be put --restrictedexec earlier on the
new command
line. I'll work on that.
The probem is apparently the one I identified above, and is fixed by
the attached patch, which I will apply soon unless there are
Magnus Hagander wrote:
The solution would be put --restrictedexec earlier on the
new command
line. I'll work on that.
The probem is apparently the one I identified above, and is
fixed by the attached patch, which I will apply soon unless
there are objections.
As for
> >> I will add some trace writes when I get a chance. I was
> rather hoping
> >> something would jump out at you, but obviously it hasn't, so I'll
> >> have to dig into it the slow way. *sigh*
> >
> >
> >
> > Just eyeballing the code it looks to me like the problem is
> this line:
> >
> >
Andrew Dunstan wrote:
I wrote:
I will add some trace writes when I get a chance. I was rather hoping
something would jump out at you, but obviously it hasn't, so I'll
have to dig into it the slow way. *sigh*
Just eyeballing the code it looks to me like the problem is this line:
I wrote:
I will add some trace writes when I get a chance. I was rather hoping
something would jump out at you, but obviously it hasn't, so I'll have
to dig into it the slow way. *sigh*
Just eyeballing the code it looks to me like the problem is this line:
strcat(cmdline, *" --rest
> >Are you running this with an admin account or a non-admin
> account? If
> >admin, what are the permissions on the initdb.exe file and libpq.dll?
> >
> >
>
> Should be unprivileged - it's the account I use to run
> buildfarm. (and which has therefore in each case just
> successfully run "
Magnus Hagander wrote:
I get a popup box that says:
initdb.exe has encountered a problem and needs to close.
We are sorry for the inconvenience.
Clicking a link gives this info:
AppName: initdb.exe AppVer: 8.2.0.6051 ModName: msvcrt.dll
ModVer: 7.0.2600.1106Offset: 00033830
I
> >>This took me hours to find ...
> >>
> >>On my Windows box, CVS HEAD gets an execution failure on
> "initdb foo"
> >>but succeeds happily with "initdb -D foo".
> >>
> >>This is not true for REL8_1_STABLE, nor is it true for all Windows
> >>machines/environments, apparently, otherwise we woul
Magnus Hagander wrote:
This took me hours to find ...
On my Windows box, CVS HEAD gets an execution failure on "initdb foo"
but succeeds happily with "initdb -D foo".
This is not true for REL8_1_STABLE, nor is it true for all
Windows machines/environments, apparently, otherwise we would
b
> This took me hours to find ...
>
> On my Windows box, CVS HEAD gets an execution failure on "initdb foo"
> but succeeds happily with "initdb -D foo".
>
> This is not true for REL8_1_STABLE, nor is it true for all
> Windows machines/environments, apparently, otherwise we would
> be seeing fa
This took me hours to find ...
On my Windows box, CVS HEAD gets an execution failure on "initdb foo"
but succeeds happily with "initdb -D foo".
This is not true for REL8_1_STABLE, nor is it true for all Windows
machines/environments, apparently, otherwise we would be seeing failures
from t
15 matches
Mail list logo
