Re: parallel restore

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: parallel restore
Date: 2009-02-02 15:49:18
Message-ID: 13494.1233589758@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Peter Eisentraut <peter_e(at)gmx(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Joshua Brindle 2009-02-02 15:50:12 Re: How to get SE-PostgreSQL acceptable
Previous Message Tom Lane 2009-02-02 15:34:36 Re: why declare arg as a array in FunctionCallInfoData structure