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
