On Thu, Nov 21, 2019 at 08:18:08AM -0800, Adrian Klaver wrote: > On 11/21/19 8:12 AM, stan wrote: > Please reply to list also > Ccing list. > > On Thu, Nov 21, 2019 at 07:56:10AM -0800, Adrian Klaver wrote: > > > On 11/21/19 6:35 AM, stan wrote: > > > > > If the 1st rule matches, I am thinking this will override any rule I put in > > > > after such as: > > > > > > > > local all postgres md5 > > > > > > > > Is my understanding of this correct? > > > > > > Yes. > > > > > > The question is whether you really need a password connection to a local > > > socket or not? > > > > > > If so then you will need to make the change and deal with any scripts that > > > are expecting a password free socket connection. > > > > > > If not leave it alone. If you want to test password connection then use a -h > > > localhost to get a host connection. > > > > > > > > > > Ugly. Thanks though I think I can skin this cat with a dfferent tool. I am > > going to try setting te needed users as the posgres db superuser. > > I would avoid that if at all possible, a superuser can wreak a lot of havoc > intentionally or unintentionally. > > It would help if you could spell out what you want to achieve, as I am sure > it has been done before by multiple people on this list. > Can do. At the moment, I have 2 instances one production and one sandbox. I want to be able to run pg_dump -d "production", take the resultant file to the sandbox and recreate a duplicate instance to do testing against. I would prefer that this not involve changing UNIX users to the postgres user, just to do this. -- "They that would give up essential liberty for temporary safety deserve neither liberty nor safety." -- Benjamin Franklin
