[ale] Postgresql start issues

[Jim Kinney]

I'm not positive but I think a reload won't affect exusting connections. So
an application with a number of dedicated connects will not see a change
untul a connection is closed and reopened.  PG aggressively keeps
connections open as long as the client requests unless explicit limits are
set.
On Oct 7, 2012 11:30 AM, "Lightner, Jeff" <JLightner at water.com> wrote:

> Thanks but I believe that last message is the result of the messages above
> it.   That is to say it isn't saying it can't READ the pg_hba.conf but that
> it can't LOAD it because the permissions it found within it don't allow it
> to continue through the load.   As I noted changing it to md5 DID make it
> LOAD.   Our issue was that later batch processes wouldn't run.
>
> After I sent the email and doing more investigation I found that the
> problem was that Postgres had last been restarted in May but someone had
> modified the pg_hba.conf in June so when we did the maintenance early
> Friday morning it was the first time the modified pg_hba.conf was used.
> Prior to June the pg_hba.conf had local set to "trust" and it was changing
> to "password" in June that caused our problem.    The DBAs agree that this
> finding is correct and that reverting to "trust" would resolve the issue we
> ran into the other night.   Of course using "trust" is not a good thing
> because it allows any local user on the Postgres server to access the DB
> but at least it explains why we saw the issue.   DBAs will do further work
> to determine best authentication method and if necessary adjust batch
> processes to deal with the better security.
>
> The question they still have is why the pg_ctl reload didn't make the
> newer settings take effect and cause problems when they ran that nightly
> for the hot backups they were running.   My read of the document says this
> command reloads settings not required for database start so I suspect the
> reason it didn't cause problem is because it didn't reload local because
> local IS required for database start.   If anyone can explain it better I'd
> appreciate it.
>
>
>
>
>
> -----Original Message-----
> From: ale-bounces at ale.org [mailto:ale-bounces at ale.org] On Behalf Of Doug
> Hall
> Sent: Saturday, October 06, 2012 12:30 AM
> To: Atlanta Linux Enthusiasts
> Subject: Re: [ale] Postgresql start issues
>
> The most bothersome message I see is the last one:
>
> FATAL:  could not load pg_hba.conf
>
> If it can't load the pg_hba.conf file, it can't tell what forms of
> authentication you are permitting. Are you starting the process as the
> postgres user? If not, this is the standard way to do that. Perhaps file
> permissions are getting in the way if not. Could file permissions have
> changed? Perhaps it didn't shut down properly. Check the log file to make
> sure it has. Otherwise, it might be a stale socket that's not letting it
> start properly.
>
> Doug
> _______________________________________________
> Ale mailing list
> Ale at ale.org
> http://mail.ale.org/mailman/listinfo/ale
> See JOBS, ANNOUNCE and SCHOOLS lists at
> http://mail.ale.org/mailman/listinfo
>
>
>
>
> Athena(r), Created for the Cause(tm)
> Making a Difference in the Fight Against Breast Cancer
>
> ---------------------------------
> CONFIDENTIALITY NOTICE: This e-mail may contain privileged or confidential
> information and is for the sole use of the intended recipient(s). If you
> are not the intended recipient, any disclosure, copying, distribution, or
> use of the contents of this information is prohibited and may be unlawful.
> If you have received this electronic transmission in error, please reply
> immediately to the sender that you have received the message in error, and
> delete it. Thank you.
> ----------------------------------
>
>
> _______________________________________________
> Ale mailing list
> Ale at ale.org
> http://mail.ale.org/mailman/listinfo/ale
> See JOBS, ANNOUNCE and SCHOOLS lists at
> http://mail.ale.org/mailman/listinfo
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.ale.org/pipermail/ale/attachments/20121007/4b94e367/attachment.html