problems with postgresql 10.1 hba_conf on fedora 27
can someone please help ?
postgresql-10
fedora 27
our hba_conf that worked with pg 9x
local all all postgres peer
host all all 127.0.0.1/32 md5
host all all ::1/128 md5
now gives error on restart and we cannot find the log file
postgres remains so damn difficult and time wasting to quickly get up
and running vs other db's and docs don't help much
--
Support Dept
Tiger Nassau, Inc.
www.tigernassau.com
406-624-9310
On Wed, Dec 20, 2017 at 4:05 PM, support-tiger <support@tigernassau.com>
wrote:
can someone please help ?
postgresql-10
fedora 27
Installed via yum?
our hba_conf that worked with pg 9x
There are six of them, which one specifically?
now gives error on restart and we cannot find the log fil
e
And what error would that be?
David J.
postgres remains so damn difficult and time wasting to quickly get up
and running vs other db's and docs don't help much
See, I feel exactly the opposite. The docs are some of the best of any database or open source software I've used. Postgres also does the "right" thing almost all the time, making it predictable.
now gives error on restart and we cannot find the log file
What error? Where did you look for the log files? Did you try running the deamon directly to see if that gives any additional information?
Jim
On December 20, 2017 6:05:39 PM EST, support-tiger <support@tigernassau.com> wrote:
can someone please help ?
postgresql-10
fedora 27
our hba_conf that worked with pg 9x
local all all postgres peer
host all all 127.0.0.1/32 md5
host all all ::1/128 md5
now gives error on restart and we cannot find the log file
postgres remains so damn difficult and time wasting to quickly get up
and running vs other db's and docs don't help much--
Support Dept
Tiger Nassau, Inc.
www.tigernassau.com
406-624-9310
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
On Wed, 2017-12-20 at 16:05 -0700, support-tiger wrote:
can someone please help ?
postgresql-10
fedora 27
our hba_conf that worked with pg 9x
local all all postgres peer
host all all 127.0.0.1/32 md5
host all all ::1/128 md5
now gives error on restart and we cannot find the log file
postgres remains so damn difficult and time wasting to quickly get
up
and running vs other db's and docs don't help much
Hi,
"local" is for socket connections, yet you have an address of
"postgres". How did this function in the past?
Exactly what do you mean by "gives error on restart". The database
starts and you can connect, then you shut it down and then you start it
again, it fails?
Cheers,
Rob
On Wednesday, December 20, 2017, rob stone <floriparob@gmail.com> wrote:
local all all postgres peer
host all all 127.0.0.1/32 md5
host all all ::1/128 md5
now gives error on restart and we cannot find the log file
"local" is for socket connections, yet you have an address of
"postgres". How did this function in the past?
Sorta, but correct enough. Local lines and host lines have differing
numbers of columns. As written the auth-method is "Postgres" with
auth-option of "md5" (i.e., there is no address column for local) which is
simply wrong. Whether it's an email typo or the actual file...
I suspect it's possible we used to ignore malformed lines whereas now we
error...
David J.
On 12/20/2017 06:33 PM, David G. Johnston wrote:
On Wednesday, December 20, 2017, rob stone <floriparob@gmail.com
<mailto:floriparob@gmail.com>> wrote:local all all postgres peer
host all all 127.0.0.1/32 <http://127.0.0.1/32> md5
host all all ::1/128 md5
now gives error on restart and we cannot find the log file
"local" is for socket connections, yet you have an address of
"postgres". How did this function in the past?Sorta, but correct enough. Local lines and host lines have differing
numbers of columns. As written the auth-method is "Postgres" with
auth-option of "md5" (i.e., there is no address column for
local) which is simply wrong. Whether it's an email typo or the
actual file...
bingo! Thks - should be "local all postgres peer" (how many times we
looked at this and didn't see it (: But if this setup is not good, we
would like to know what it should be - our case is for accessing from
Ruby app using pg gem on same server (at least for now)
No, the docs for understanding hba_conf are not good (yes we can read
and are fairly smart) - we made suggestions the last time for several
case examples and were ignored - okay, simplicity of pouchdb/couchdb is
getting our attention
I suspect it's possible we used to ignore malformed lines whereas now
we error...David J.
--
Support Dept
Tiger Nassau, Inc.
www.tigernassau.com
406-624-9310
On Wed, Dec 20, 2017 at 9:30 PM, support-tiger <support@tigernassau.com>
wrote:
No, the docs for understanding hba_conf are not good (yes we can read and
are fairly smart) - we made suggestions the last time for several case
examples and were ignored - okay, simplicity of pouchdb/couchdb is
getting our attention
Can you point to a link where the hba docs are suboptimal and suggest to
the mailing list an improvement?
-m