pg_ctl using START with paths needing quotes

This is a really ugly hack (I take the blame since I gave Bruce the
idea). There are a few things to note:

. the .bat file should probably be created in the data dir - that's
about the only place that we should be guaranteed we can write.
. the command should be preceded by '@' to suppress echoing
. the whole command, including redirections should go inside the .bat
file, so that pg_ctl just issues 'start /b foo.bat'

There are still things to clean up in pg_ctl, e.g. its handling of
relative paths to the data dir.

cheers

andrew

Bruce Momjian wrote:

Minor patch to correct erroneous warning in cvs tip, believed to be a
very minor regression.

When a shutdown was requested within CHECKPOINT_SECONDS of a checkpoint,
the shutdown code in the bgwriter (which has does checkpointing) would
issue the erroneous message:

LOG: checkpoints are occurring too frequently (%d seconds apart)
HINT: Consider increasing the configuration parameter
"checkpoint_segments".

Clearly, this should only occur when specific checkpoint requests have
been made, shutdown checkpoints should not be included in the warning.

Best regards, Simon Riggs

Andrew Dunstan wrote:

This is a really ugly hack (I take the blame since I gave Bruce the
idea). There are a few things to note:

. the .bat file should probably be created in the data dir - that's
about the only place that we should be guaranteed we can write.
. the command should be preceded by '@' to suppress echoing
. the whole command, including redirections should go inside the .bat
file, so that pg_ctl just issues 'start /b foo.bat'

There are still things to clean up in pg_ctl, e.g. its handling of
relative paths to the data dir.

Hack removed.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Andrew Dunstan <andrew@dunslane.net> writes:

Bruce Momjian wrote:

This applied patch changes the way pg_ctl starts on Win32.

Using START, it is not possible to quote the executable name, who's
directory might have spaces:

This is a really ugly hack (I take the blame since I gave Bruce the
idea). There are a few things to note:

. the .bat file should probably be created in the data dir - that's
about the only place that we should be guaranteed we can write.

In that case, haven't we simply moved the spaces problem from the
executable directory to the data directory?

regards, tom lane

Tom Lane wrote:

Andrew Dunstan <andrew@dunslane.net> writes:

Bruce Momjian wrote:

This applied patch changes the way pg_ctl starts on Win32.

Using START, it is not possible to quote the executable name, who's
directory might have spaces:

This is a really ugly hack (I take the blame since I gave Bruce the
idea). There are a few things to note:

. the .bat file should probably be created in the data dir - that's
about the only place that we should be guaranteed we can write.

In that case, haven't we simply moved the spaces problem from the
executable directory to the data directory?

Yes. you're right. The hack is gone now so it's moot.

cheers

andrew

Tom Lane wrote:

Andrew Dunstan <andrew@dunslane.net> writes:

Bruce Momjian wrote:

This applied patch changes the way pg_ctl starts on Win32.

Using START, it is not possible to quote the executable name, who's
directory might have spaces:

This is a really ugly hack (I take the blame since I gave Bruce the
idea). There are a few things to note:

. the .bat file should probably be created in the data dir - that's
about the only place that we should be guaranteed we can write.

In that case, haven't we simply moved the spaces problem from the
executable directory to the data directory?

Yep. That code is all gone now that we have the right fix, use:

START "" "executable"

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Simon Riggs <simon@2ndquadrant.com> writes:

Minor patch to correct erroneous warning in cvs tip, believed to be a
very minor regression.

This patch is wrong; it effectively disables the warning altogether.

When a shutdown was requested within CHECKPOINT_SECONDS of a checkpoint,
the shutdown code in the bgwriter (which has does checkpointing) would
issue the erroneous message:

I don't think so ... the shutdown path doesn't go through this code.
Could you take another look at the cause of what you saw?

regards, tom lane

Patch rejected, asking for more research.

---------------------------------------------------------------------------

Simon Riggs wrote:

Minor patch to correct erroneous warning in cvs tip, believed to be a
very minor regression.

When a shutdown was requested within CHECKPOINT_SECONDS of a checkpoint,
the shutdown code in the bgwriter (which has does checkpointing) would
issue the erroneous message:

LOG: checkpoints are occurring too frequently (%d seconds apart)
HINT: Consider increasing the configuration parameter
"checkpoint_segments".

Clearly, this should only occur when specific checkpoint requests have
been made, shutdown checkpoints should not be included in the warning.

Best regards, Simon Riggs

[ Attachment, skipping... ]

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Bruce Momjian wrote:

Tom Lane wrote:

Andrew Dunstan <andrew@dunslane.net> writes:

Bruce Momjian wrote:

This applied patch changes the way pg_ctl starts on Win32.

Using START, it is not possible to quote the executable name, who's
directory might have spaces:

This is a really ugly hack (I take the blame since I gave Bruce the
idea). There are a few things to note:

. the .bat file should probably be created in the data dir - that's
about the only place that we should be guaranteed we can write.

In that case, haven't we simply moved the spaces problem from the
executable directory to the data directory?

Yep. That code is all gone now that we have the right fix, use:

START "" "executable"

For the record, and in case we need to use it in future, here's what I
got working in pg_ctl.c for starting without any shell call required
(lacks error checking).

cheers

andrew

#ifdef WIN32

char exepath[MAXPGPATH];
STARTUPINFO si;
PROCESS_INFORMATION pi;
bool rval;
int null_fd, log_fd;
int save_stdin, save_stdout, save_stderr;

save_stdin = _dup(fileno(stdin));

ZeroMemory(&si,sizeof(STARTUPINFO));
si.cb = sizeof(STARTUPINFO);

null_fd = open("nul",O_RDONLY,0);
dup2(null_fd, fileno(stdin));
if (log_file != NULL)
{
save_stdout = _dup(fileno(stdout));
save_stderr = _dup(fileno(stderr));
log_fd = open(log_file,O_WRONLY|O_CREAT|O_APPEND,0700);
dup2(log_fd, fileno(stdout));
dup2(log_fd ,fileno(stderr));
}

snprintf(exepath,MAXPGPATH,"%s",postgres_path);
snprintf(cmd,MAXPGPATH,"\"%s\" %s",postgres_path,post_opts);
rval = CreateProcess(exepath,cmd,NULL,NULL,true,0,NULL,NULL,&si,&pi);
if (rval == 0)
{
CloseHandle(pi.hThread);
CloseHandle(pi.hProcess);
}
dup2(save_stdin, fileno(stdin));
close(null_fd);
if (log_file != NULL)
{
dup2(save_stdout,fileno(stdout));
dup2(save_stderr,fileno(stderr));
close(log_fd);
}
return (rval == 0);

#else

On Fri, 2004-06-11 at 19:25, Tom Lane wrote:

Simon Riggs <simon@2ndquadrant.com> writes:

Minor patch to correct erroneous warning in cvs tip, believed to be a
very minor regression.

This patch is wrong; it effectively disables the warning altogether.

When a shutdown was requested within CHECKPOINT_SECONDS of a checkpoint,
the shutdown code in the bgwriter (which has does checkpointing) would
issue the erroneous message:

I don't think so ... the shutdown path doesn't go through this code.
Could you take another look at the cause of what you saw?

Hmmm...perhaps I should submit this as a *low priority* bug then, rather
than just a patch?

As of now, (i.e. even including the new bgwriter shutdown) if you:
1. start postmaster
2. do some work that writes xlog
3. shutdown within some few seconds of startup

you get a WARNING suggesting you increase CHECKPOINT_SEGMENTS, which is
clearly erroneous since no checkpoint has taken place since startup.

Not exactly a common circumstance, I grant you, but it does seem to be a
regression nonetheless. My thinking was that the circumstance was not
limited to this edge case, but actually any shutdown within 30s of a
checkpoint, but the latter is just speculation.

Only reason I spotted it is I've been doing a lot of startup/shutdown
work recently...

Best Regards, Simon Riggs

Simon Riggs <simon@2ndquadrant.com> writes:

As of now, (i.e. even including the new bgwriter shutdown) if you:
1. start postmaster
2. do some work that writes xlog
3. shutdown within some few seconds of startup
you get a WARNING suggesting you increase CHECKPOINT_SEGMENTS, which is
clearly erroneous since no checkpoint has taken place since startup.

[ scratches head... ] Not for me. Are you using any nondefault
settings in postgresql.conf?

regards, tom lane

On Tue, 2004-06-15 at 19:33, Tom Lane wrote:

Simon Riggs <simon@2ndquadrant.com> writes:

As of now, (i.e. even including the new bgwriter shutdown) if you:
1. start postmaster
2. do some work that writes xlog
3. shutdown within some few seconds of startup
you get a WARNING suggesting you increase CHECKPOINT_SEGMENTS, which is
clearly erroneous since no checkpoint has taken place since startup.

[ scratches head... ] Not for me. Are you using any nondefault
settings in postgresql.conf?

Hmmm...I did a complete re-download of CVS, then a vanilla
configure/make/make install.... with .conf straight from can. I wanted
to be absolutely certain I had got it clean.

Shutdown was via CTRL-C....make a difference?

Damn I hate the wierd ones...if only because of the 90% chance its
something wrong that I've done...

I'll do it again more slowly and report back...

Best Regards, Simon Riggs

Simon Riggs <simon@2ndquadrant.com> writes:

Shutdown was via CTRL-C....make a difference?

Wouldn't think so.

I can force the message to appear if I do a *manual* CHECKPOINT command
within thirty seconds of startup. I'm not sure if that should be
considered wrong or not, but in any case it doesn't seem to be what
you're describing.

regards, tom lane

Tom Lane wrote:

Simon Riggs <simon@2ndquadrant.com> writes:

Shutdown was via CTRL-C....make a difference?

Wouldn't think so.

I can force the message to appear if I do a *manual* CHECKPOINT command
within thirty seconds of startup. I'm not sure if that should be
considered wrong or not, but in any case it doesn't seem to be what
you're describing.

Just to confirm that Simon is not suffering this uniquely, I saw this
the other day on Windows, I believe - meant to report it but it got away
from me.

cheers

andrew

Andrew Dunstan <andrew@dunslane.net> writes:

Just to confirm that Simon is not suffering this uniquely, I saw this
the other day on Windows, I believe - meant to report it but it got away
from me.

Oh, I bet I know what's going on --- are you guys launching the
postmaster in a console window and then typing ^C to shut it down?
Depending on your shell that might result in SIGINT being delivered
not only to the postmaster but to all its children. Backends, if
any, will take that as a query-cancel while the bgwriter will take
it as a checkpoint request. Which could easily result in the
too-frequent-checkpoints message.

The only real fix I can see for this is to use some other signal than
SIGINT to transmit checkpoint requests to the bgwriter. Maybe we could
piggyback all bgwriter requests onto SIGUSR2, comparable to the way that
signals up to the postmaster are now handled. Not sure how important
it is though.

regards, tom lane

On Tue, 2004-06-15 at 21:04, Tom Lane wrote:

Andrew Dunstan <andrew@dunslane.net> writes:

Just to confirm that Simon is not suffering this uniquely, I saw this
the other day on Windows, I believe - meant to report it but it got away
from me.

Oh, I bet I know what's going on --- are you guys launching the
postmaster in a console window and then typing ^C to shut it down?
Depending on your shell that might result in SIGINT being delivered
not only to the postmaster but to all its children. Backends, if
any, will take that as a query-cancel while the bgwriter will take
it as a checkpoint request. Which could easily result in the
too-frequent-checkpoints message.

The only real fix I can see for this is to use some other signal than
SIGINT to transmit checkpoint requests to the bgwriter. Maybe we could
piggyback all bgwriter requests onto SIGUSR2, comparable to the way that
signals up to the postmaster are now handled. Not sure how important
it is though.

Sounds like the cause to me...that would explain why it has just started
happening...

Its minor then... I would only do that for testing...

Regards, Simon

Tom Lane wrote:

Simon Riggs <simon@2ndquadrant.com> writes:

Shutdown was via CTRL-C....make a difference?

Wouldn't think so.

I can force the message to appear if I do a *manual* CHECKPOINT command
within thirty seconds of startup. I'm not sure if that should be
considered wrong or not, but in any case it doesn't seem to be what
you're describing.

It is wrong. The message should not appear if you issue CHECKPOINT.

I just did CHECKPOINT;CHECKPOINT and got the warning in the logs. This
needs to be fixed.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Bruce Momjian <pgman@candle.pha.pa.us> writes:

I just did CHECKPOINT;CHECKPOINT and got the warning in the logs. This
needs to be fixed.

See code:

/*
* Ideally we should only warn if this checkpoint was
* requested due to running out of segment files, and not
* if it was manually requested. However we can't tell the
* difference with the current signalling mechanism.
*/

I could argue that a client-driven process that issues CHECKPOINT every
few seconds is equally deserving of a warning. The only thing wrong is
that the HINT is inapplicable ... but that's why it's a HINT and not
part of the main message.

regards, tom lane

Tom Lane wrote:

Bruce Momjian <pgman@candle.pha.pa.us> writes:

I just did CHECKPOINT;CHECKPOINT and got the warning in the logs. This
needs to be fixed.

See code:

/*
* Ideally we should only warn if this checkpoint was
* requested due to running out of segment files, and not
* if it was manually requested. However we can't tell the
* difference with the current signalling mechanism.
*/

I could argue that a client-driven process that issues CHECKPOINT every
few seconds is equally deserving of a warning. The only thing wrong is
that the HINT is inapplicable ... but that's why it's a HINT and not
part of the main message.

Also consider they could have issued a checkpoint right after the system
did one. Yuck.

When I added the warning I hoped to only have it happen for full logs
and not CHECKPOINT, but I guess I couldn't and someone else realized
that and added that clearer comment, or originally I could do that, but
since it has been moved into the bgwriter, it can't anymore.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073