pg_hba.conf changes without restarting postmaster

Hello.

It seems that every time I make a change to pg_hba.conf, I have to
restart the database server for the new authentication to take effect.
Is there a way to have the server use the new pg_hba.conf authentication
without restarting the production server.

Thanks,

Si


---------------------------(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

re: pg_hba.conf changes without restarting postmaster

Si Chen <schen@graciousstyle.com> wrote:[color=blue]
>
> Hello.
>
> It seems that every time I make a change to pg_hba.conf, I have to
> restart the database server for the new authentication to take effect.
> Is there a way to have the server use the new pg_hba.conf authentication
> without restarting the production server.[/color]

The documentation is your friend.

Excerpt from $PGDATA/pg_hba.conf:
....
# This file is read on server startup and when the postmaster receives
# a SIGHUP signal. If you edit the file on a running system, you have
# to SIGHUP the postmaster for the changes to take effect, or use
# "pg_ctl reload".
....

And...

$ man pg_ctl
....
reload mode simply sends the postmaster process a SIGHUP
signal, causing it to reread its configuration files
(postgresql.conf, pg_hba.conf, etc.). This allows changing
of configuration-file options that do not require a complete
restart to take effect.
....

Jim

---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

re: pg_hba.conf changes without restarting postmaster

After a long battle with technology, schen@graciousstyle.com (Si Chen), an earthling, wrote:[color=blue]
> It seems that every time I make a change to pg_hba.conf, I have to
> restart the database server for the new authentication to take effect.
> Is there a way to have the server use the new pg_hba.conf
> authentication without restarting the production server.[/color]

You NEVER need to restart the database server to reflect pg_hba.conf
changes.

The command "pg_ctl -D $PGDATA reload" will cause the server to reload
the contents of pg_hba.conf, assuming PGDATA is appropriately set.
Several other methods are possible, all of which ultimately amount to
sending the signal SIGHUP to the postmaster.
--
(format nil "~S@~S" "cbbrowne" "ntlug.org")
http://www3.sympatico.ca/cbbrowne/linux.html
I found out why cats drink out of the toilet. My mother told me it's
because it's cold in there. And I'm like: How did my mother know THAT?
--Wendy Liebman

re: pg_hba.conf changes without restarting postmaster

If you launch your progress server at startup (in init.d),
you only have to type :
# service postgresql reload
It works fine.
Luc

----- Original Message -----
From: "Christopher Browne" <cbbrowne@acm.org>
To: <pgsql-general@postgresql.org>
Sent: Saturday, July 31, 2004 3:09 AM
Subject: Re: [GENERAL] pg_hba.conf changes without restarting postmaster

[color=blue]
> After a long battle with technology, schen@graciousstyle.com (Si Chen), an[/color]
earthling, wrote:[color=blue][color=green]
> > It seems that every time I make a change to pg_hba.conf, I have to
> > restart the database server for the new authentication to take effect.
> > Is there a way to have the server use the new pg_hba.conf
> > authentication without restarting the production server.[/color]
>
> You NEVER need to restart the database server to reflect pg_hba.conf
> changes.
>
> The command "pg_ctl -D $PGDATA reload" will cause the server to reload
> the contents of pg_hba.conf, assuming PGDATA is appropriately set.
> Several other methods are possible, all of which ultimately amount to
> sending the signal SIGHUP to the postmaster.
> --
> (format nil "~S@~S" "cbbrowne" "ntlug.org")
> http://www3.sympatico.ca/cbbrowne/linux.html
> I found out why cats drink out of the toilet. My mother told me it's
> because it's cold in there. And I'm like: How did my mother know THAT?
> --Wendy Liebman
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
>
> http://archives.postgresql.org
>
>[/color]


---------------------------(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