Re: pg_ctl

I briefly reviewed the alpha version of this that Joshua posted a URL to
(after converting all the c++ style comments and running through
pgindent so I could read it).

I endorse Neil's and Bruce's comments. In addition, I noticed these things:

. on Win32 a start op is guaranteed to hang unless I'm misreading the
code, as it is not backgrounded. Calling system() won't work here - I
think we'll have to call CreateProcess() on Win32.
. what about devnull processing on Win32?
. multi-line literals are apparently illegal (see recent hackers
thread?) and rejected by some compilers - use the fact that the compiler
will concatentate adjacent string literals.
. there is a lot of incorrect code that tries to do things that are
already done correctly and portably in initdb.c - e.g. finding the
postmaster executable.
. calling fopen() to check existence of a file is, er, suboptimal. Use
stat().
. no error checking on malloc() calls
. calling free() on these tiny strings is quite unnecessary - the
program should use minimal memory and have a very short life span. It's
just useless clutter IMNSHO.

This isn't an exhaustive list.

I suspect this work is actually a bit premature, and would best be done
after we have a working Win32 postmaster. After all, you can happily run
postgres without ever calling pg_ctl - it's a convenience rather than an
absolute necessity (unlike initdb). On Windows, production users
probably wouldn't use it at all - they would use the service manager, I
should think.

cheers

andrew

Communicated.

Andrew Dunstan wrote:

>
> I briefly reviewed the alpha version of this that Joshua posted a URL
> to (after converting all the c++ style comments and running through
> pgindent so I could read it).
>
> I endorse Neil's and Bruce's comments. In addition, I noticed these
> things:
>
> . on Win32 a start op is guaranteed to hang unless I'm misreading the
> code, as it is not backgrounded. Calling system() won't work here - I
> think we'll have to call CreateProcess() on Win32.
> . what about devnull processing on Win32?
> . multi-line literals are apparently illegal (see recent hackers
> thread?) and rejected by some compilers - use the fact that the
> compiler will concatentate adjacent string literals.
> . there is a lot of incorrect code that tries to do things that are
> already done correctly and portably in initdb.c - e.g. finding the
> postmaster executable.
> . calling fopen() to check existence of a file is, er, suboptimal. Use
> stat().
> . no error checking on malloc() calls
> . calling free() on these tiny strings is quite unnecessary - the
> program should use minimal memory and have a very short life span.
> It's just useless clutter IMNSHO.
>
> This isn't an exhaustive list.
>
> I suspect this work is actually a bit premature, and would best be
> done after we have a working Win32 postmaster. After all, you can
> happily run postgres without ever calling pg_ctl - it's a convenience
> rather than an absolute necessity (unlike initdb). On Windows,
> production users probably wouldn't use it at all - they would use the
> service manager, I should think.
>
> cheers
>
> andrew
>
>
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to majordomo(at)postgresql(dot)org

--
Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC
Postgresql support, programming shared hosting and dedicated hosting.
+1-503-667-4564 - jd(at)commandprompt(dot)com - http://www.commandprompt.com
Mammoth PostgreSQL Replicator. Integrated Replication for PostgreSQL

Back on December 1st I wrote:

>
>
> I suspect this work is actually a bit premature, and would best be
> done after we have a working Win32 postmaster. After all, you can
> happily run postgres without ever calling pg_ctl - it's a convenience
> rather than an absolute necessity (unlike initdb). On Windows,
> production users probably wouldn't use it at all - they would use the
> service manager, I should think.
>
>

Are we now in a state where it would make sense to look at doing pg_ctl
in C?

(And has anyone looked at putting in service manager hooks?)

cheers

andrew

Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> Are we now in a state where it would make sense to look at doing pg_ctl
> in C?

Why bother? I should think that Windows users want to run PG as a service.

regards, tom lane

Tom Lane wrote:

>Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
>
>
>>Are we now in a state where it would make sense to look at doing pg_ctl
>>in C?
>>
>>
>
>Why bother? I should think that Windows users want to run PG as a service.
>
>

Not unreasonable. Maybe someone who uses/distributes a commercial
Windows version can inform us about usage patterns. If that's what we
decide we should remove this from the Win32 page:

. Create C version of pg_ctl?

And while on the subject of that page, this issue should now be fixed
with the listen_addresses patch (which I hope someone can verify):

Postmaster must be started with -i flag, or with tcpip_socket = true in
postgresql.conf, else the postmaster will fail to start and issue the
following error:
|LOG: select() failed in postmaster: No such file or directory

cheers

andrew
|

> Not unreasonable. Maybe someone who uses/distributes a commercial
> Windows version can inform us about usage patterns. If that's what we
> decide we should remove this from the Win32 page:
>
> . Create C version of pg_ctl?
>
Well we are (although it is on the back burner) working on pg_ctl in C.

Our experience is that all of our customers who run our Cygwin based
version prefer it running as a service.

> And while on the subject of that page, this issue should now be fixed
> with the listen_addresses patch (which I hope someone can verify):
>
> Postmaster must be started with -i flag, or with tcpip_socket = true
> in postgresql.conf, else the postmaster will fail to start and issue
> the following error:
> |LOG: select() failed in postmaster: No such file or directory
>
>
> cheers
>
>
> andrew
> |
>
> ---------------------------(end of broadcast)---------------------------
> TIP 9: the planner will ignore your desire to choose an index scan if
> your
> joining column's datatypes do not match

--
Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC
Postgresql support, programming shared hosting and dedicated hosting.
+1-503-667-4564 - jd(at)commandprompt(dot)com - http://www.commandprompt.com
PostgreSQL Replicator -- production quality replication for PostgreSQL

Joshua D. Drake wrote:
>
> > Not unreasonable. Maybe someone who uses/distributes a commercial
> > Windows version can inform us about usage patterns. If that's what we
> > decide we should remove this from the Win32 page:
> >
> > . Create C version of pg_ctl?
> >
> Well we are (although it is on the back burner) working on pg_ctl in C.
>
> Our experience is that all of our customers who run our Cygwin based
> version prefer it running as a service.

We should make pg_ctl a C program. Some package installer or something
will need it. It is only 412 lines of shell script.

> > And while on the subject of that page, this issue should now be fixed
> > with the listen_addresses patch (which I hope someone can verify):
> >
> > Postmaster must be started with -i flag, or with tcpip_socket = true
> > in postgresql.conf, else the postmaster will fail to start and issue
> > the following error:
> > |LOG: select() failed in postmaster: No such file or directory

Win32 project page updated:

http://momjian.postgresql.org/main/writings/pgsql/project

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

Tom Lane wrote:
>>Are we now in a state where it would make sense to look at doing pg_ctl
>>in C?
>
> Why bother? I should think that Windows users want to run PG as a service.

Except when a non administrator wants to run his own PG instance.

--
dave