Re: Disabling trust/ident authentication configure option - Mailing list pgsql-hackers

From Jim Nasby
Subject Re: Disabling trust/ident authentication configure option
Date
Msg-id 555D2817.3060700@BlueTreble.com
Whole thread Raw
In response to Re: Disabling trust/ident authentication configure option  (Stephen Frost <sfrost@snowman.net>)
List pgsql-hackers
On 5/20/15 7:19 PM, Stephen Frost wrote:
> * Andres Freund (andres@anarazel.de) wrote:
>> >On 2015-05-20 19:46:12 -0400, Stephen Frost wrote:
>>> > >In other words, I agree with you that we can't simply get rid of 'trust'
>>> > >without having another solution.  I*do*  believe that a real single-user
>>> > >mode that is only available to the owner of the cluster would go a long
>>> > >way towards this goal.
>> >
>> >I think that's a restriction that doesn't make much sense. What if you
>> >want to dump the data as fast as possible to get things up in another
>> >machine/datacenter/whatever after a fault? Uh wait, parallel dump won't
>> >work with single user mode.
> We're talking about vaporware here at the moment, so I'll just throw out
> that, perhaps, you could have multiple PG instances in single-user which
> are all running at the same time in a read-only fashion.:)
>
> Actually, having a tool like that would be*really*  handy for a lot of
> uses.  In some ways, I believe our lack of such tooling is specifically
> because we simply don't have as many issues in this area as other
> databases do.  Where is a tool to extract out all the records (with
> their system columns) from a file based on a provided table definition?
> With that, you could certainly parallelize pulling all of the data out
> into flat files.

Now that we have shared memory queues, perhaps it wouldn't be that hard 
to use them as an alternative communication method. OS handles auth for 
you (and I'd hope this would work in windows too...)
-- 
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com



pgsql-hackers by date:

Previous
From: Jim Nasby
Date:
Subject: Re: Change pg_cancel_*() to ignore current backend
Next
From: Tom Lane
Date:
Subject: Re: Change pg_cancel_*() to ignore current backend