Re: parallel restore - Mailing list pgsql-hackers

From Tom Lane
Subject Re: parallel restore
Date
Msg-id 13494.1233589758@sss.pgh.pa.us
Whole thread Raw
In response to Re: parallel restore  (Peter Eisentraut <peter_e@gmx.net>)
Responses Re: parallel restore  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Peter Eisentraut <peter_e@gmx.net> writes:
> Andrew Dunstan wrote:
>> I didn't know such a thing even existed. What causes it to happen? I 
>> agree it should be forbidden.

> It was the only way to switch users before we had SET SESSION 
> AUTHORIZATION and SET ROLE and such.  But the pg_restore man page says 
> that -R/--no-reconnect is obsolete, so I'm not sure what the current 
> behavior really is.

Yeah, I think I was remembering ancient history.  AFAICT we now never
do a reconnect with anything but the originally specified username.

I thought for a bit about stripping out the apparent flexibility to
use other names, and making these low-level functions just consult
ropt->username for themselves.  But we might regret that someday.
What's probably better is to have them notice whether the argument
is ropt->username, and only attempt to cache the password if so.

I'm almost done reviewing the patch, and will send along an updated
version shortly.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: why declare arg as a array in FunctionCallInfoData structure
Next
From: Joshua Brindle
Date:
Subject: Re: How to get SE-PostgreSQL acceptable