Обсуждение: postgres startup script, long delay when auth = password

if pg_hba.conf has local users "trust"ed, reboots are quick and painless.  there
are obvious security problems with this though.

in switching the auth to password for example, we end up with the startup script
hanging on reboot... not indefinately though.  When running the startup script
manually from the shell, it it non-responsive for about 45-60 seconds, then
issues the "pg_ctl: postmaster does not start" error.

vs2# ./010* start
pg_ctl: postmaster does not start
 pgsqlvs2#

however after finally regaining the prompt, we check and the postmaster did
indeed start and is running...

vs2# ./010* status
pg_ctl: postmaster is running (pid: 35157)
Command line was:
/usr/local/bin/postmaster
vs2#

this delay during the boot process causes all rc.d scripts in this directory
after the postgres script not to be started on bootup...  most annoying.

Here is the relavent line in the startup script (basic from FreeBSD 4.3 port)

case $1 in
start)
    [ -d /usr/local/lib ] && /sbin/ldconfig -m /usr/local/lib
    [ -x ${PGBIN}/pg_ctl ] && {
        su -l pgsql -c \
            '[ -d ${PGDATA} ] && exec /usr/local/bin/pg_ctl start -s -w -l ~pgs
        echo -n ' pgsql'
    }
    ;;

could just remove the -w tag and presumably this would eliminate the 60 second
wait...  but then we wouldn't actually be verifying that the startup was
successful either.

Is it actually taking that long for the database to start? or is pg_ctl not
picking up on whatever indicator it uses to determine that the database has
indeed started?

Appreciate the input.

Dave

"Dave" <dave@hawk-systems.com> writes:
> Is it actually taking that long for the database to start? or is pg_ctl not
> picking up on whatever indicator it uses to determine that the database has
> indeed started?

The "indicator" is whether it can connect with psql or not;
unfortunately it is not bright enough to distinguish a password failure
from other failures.  You might be entertained to read Peter E's
commentary near the bottom of pg_ctl (it's only a shell script,
feel free to take a look).

Perhaps pg_ctl could be enhanced to distinguish connection failures
(which is what it really cares about) from authorization failures.
Or maybe there's some other way that would address Peter's other gripes.
I have no time to think about it, but if anyone wants to work on it ...

            regards, tom lane

I recently asked about adding DBD:PG to Novell and got the reply that it should
be possible since novell supports DBI.

However, Since I cannot install / build PostgreSQL on a novell machine I do not
satisfy the requirments for building DMD:Pg.

How can I add either of the mentioned perl modules to a machine that does not
have the postgresql libraries?

I have the libraries built on a linux/x86 box. Can I just copy them to the
novell server( I 99.99999% sure the answer to this question is no)?

Thanks for your help!

Jeff Post

and again if you send a letter to Enhancements@novell.com to ask them to add
PostgreSQL support I would appreciate it!

Jeff Post <postjeff@uwm.edu> writes:

> I recently asked about adding DBD:PG to Novell and got the reply
> that it should be possible since novell supports DBI.
>
> However, Since I cannot install / build PostgreSQL on a novell
> machine I do not satisfy the requirments for building DMD:Pg.
>
> How can I add either of the mentioned perl modules to a machine that
> does not have the postgresql libraries?
>
> I have the libraries built on a linux/x86 box. Can I just copy them to the
> novell server( I 99.99999% sure the answer to this question is no)?

Nope.  You're either going to have to port the libraries to NetWare
(which might not be too hard) or write a "pure Perl" implementation of
DBD::Pg (one that speaks the backend protocol directly rather than
using the libraries).  The former is almost certainly less work.  I
know there was someone on -hackers working on a NetWare port; you
might want to search the archives for that list.

-Doug
--
Doug McNaught       Wireboard Industries      http://www.wireboard.com/

      Custom software development, systems and network consulting.
      Java PostgreSQL Enhydra Python Zope Perl Apache Linux BSD...

In article <m3wuv32wp5.fsf@varsoon.wireboard.com>,
Doug McNaught  <doug@wireboard.com> wrote:
>Nope.  You're either going to have to port the libraries to NetWare
>(which might not be too hard) or write a "pure Perl" implementation of
>DBD::Pg (one that speaks the backend protocol directly rather than
>using the libraries).  The former is almost certainly less work.  I
>know there was someone on -hackers working on a NetWare port; you
>might want to search the archives for that list.


The JDBC driver is a pure Java implementation, correct?

Would that be a decent enough starting place for a pure Perl version?

mrc
--
     Mike Castle      dalgoda@ix.netcom.com      www.netcom.com/~dalgoda/
    We are all of us living in the shadow of Manhattan.  -- Watchmen
fatal ("You are in a maze of twisty compiler features, all different"); -- gcc

dalgoda@ix.netcom.com (Mike Castle) writes:

> In article <m3wuv32wp5.fsf@varsoon.wireboard.com>,
> Doug McNaught  <doug@wireboard.com> wrote:
> >Nope.  You're either going to have to port the libraries to NetWare
> >(which might not be too hard) or write a "pure Perl" implementation of
> >DBD::Pg (one that speaks the backend protocol directly rather than
> >using the libraries).  The former is almost certainly less work.  I
> >know there was someone on -hackers working on a NetWare port; you
> >might want to search the archives for that list.
>
>
> The JDBC driver is a pure Java implementation, correct?

Yes.

> Would that be a decent enough starting place for a pure Perl version?

That, plus the chapter in the docs that deals with the wire protocol.

The main downside to doing the above is that you have to track the
wire protocol yourself, rather than relying on libpq to do it for
you.

-Doug
--
Doug McNaught       Wireboard Industries      http://www.wireboard.com/

      Custom software development, systems and network consulting.
      Java PostgreSQL Enhydra Python Zope Perl Apache Linux BSD...