Thread: pg_dump no longer honors --no-reconnect
From CVS logs I see: pg_dump/pg_restore now alwaysuse SET SESSION AUTHORIZATION, not\connect, to control object ownership. Theuse-set-session-authorization and no-reconnectswitches are obsolete(still accepted on the command line, but they don't do anything). Thisis a precursor tofixing handling of CREATE SCHEMA, which will be aseparate commit. This was to fix a problem with restoring schemas. However, the commit says that --use-set-session-authorization and --no-reconnect are no longer honored. Seems we can silently ignore a --use-set-session-authorization flag because that is now the default, but I don't see how we can ignore a --no-reconnect flag --- we should throw an error. The pg_dump manual says:-R--no-reconnect This option is obsolete but still accepted for backwards compatibility. Also, the 7.3 manual mentions that only the super-user can restore using --use-set-session-authorization. This is now the only way to create dumps. Seems this is a new limitation to pg_dump that we didn't discuss. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Bruce Momjian writes: > Seems we can silently ignore a --use-set-session-authorization flag > because that is now the default, but I don't see how we can ignore a > --no-reconnect flag --- we should throw an error. Why? The new bevavior of pg_dump is to never reconnect -- exactly the point of this change. > Also, the 7.3 manual mentions that only the super-user can restore using > --use-set-session-authorization. This is now the only way to create > dumps. Seems this is a new limitation to pg_dump that we didn't > discuss. It had been dicussed on and off for quite some time. This limitation should only apply if you create dumps that contain objects owned by more than one user. (Does it? I didn't check.) -- Peter Eisentraut peter_e@gmx.net
Peter Eisentraut wrote: > Bruce Momjian writes: > > > Seems we can silently ignore a --use-set-session-authorization flag > > because that is now the default, but I don't see how we can ignore a > > --no-reconnect flag --- we should throw an error. > > Why? The new bevavior of pg_dump is to never reconnect -- exactly the > point of this change. Oh, sorry, I see now. I got --no-reconnect confused with --reconnect, which would say we want to reconnect. I now see the option handling is fine because we do both by default. > > Also, the 7.3 manual mentions that only the super-user can restore using > > --use-set-session-authorization. This is now the only way to create > > dumps. Seems this is a new limitation to pg_dump that we didn't > > discuss. > > It had been dicussed on and off for quite some time. This limitation > should only apply if you create dumps that contain objects owned by more > than one user. (Does it? I didn't check.) Yes, but didn't the old code prompt you for passwords, or silently work if you had things set to 'trust', while our new code requires super-user? -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> but I don't see how we can ignore a --no-reconnect flag --- we should
> throw an error.
We can ignore it because we don't reconnect. I only took out the flag
because I noticed it was no longer tested anywhere after I removed the
\connect code paths. I'm not sure if the old docs mentioned that
--no-reconnect was irrelevant when using set-session-authorization,
but that's how the code behaved.
> Also, the 7.3 manual mentions that only the super-user can restore using
> --use-set-session-authorization. This is now the only way to create
> dumps. Seems this is a new limitation to pg_dump that we didn't
> discuss.
No, because a non-superuser can still restore with --no-owner; which is
actually a step forward over what he could have done with a \connect script.
(Unless you think that the scenario of a non-superuser who knows
everyone's password is something pg_dump needs to cater to.)
regards, tom lane
Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > but I don't see how we can ignore a --no-reconnect flag --- we should > > throw an error. > > We can ignore it because we don't reconnect. I only took out the flag > because I noticed it was no longer tested anywhere after I removed the > \connect code paths. I'm not sure if the old docs mentioned that > --no-reconnect was irrelevant when using set-session-authorization, > but that's how the code behaved. > > > Also, the 7.3 manual mentions that only the super-user can restore using > > --use-set-session-authorization. This is now the only way to create > > dumps. Seems this is a new limitation to pg_dump that we didn't > > discuss. > > No, because a non-superuser can still restore with --no-owner; which is > actually a step forward over what he could have done with a \connect script. > (Unless you think that the scenario of a non-superuser who knows > everyone's password is something pg_dump needs to cater to.) Oh, OK, thanks. My initial mistake was reading --no-reconnect as --reconnect; not sure how I did that. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Peter Eisentraut wrote:
>> It had been dicussed on and off for quite some time. This limitation
>> should only apply if you create dumps that contain objects owned by more
>> than one user. (Does it? I didn't check.)
> Yes, but didn't the old code prompt you for passwords, or silently work
> if you had things set to 'trust', while our new code requires
> super-user?
If you have things set to "trust", you can be superuser, eh?
A password approach might be workable using ~/.pgpass, but only in a
scenario where (a) a non-superuser has everyone else's passwords in his
~/.pgpass, and (b) there are no superuser-owned objects in the dump.
Neither of those assumptions hold up to scrutiny.
In practice I think use-set-session-auth is vastly the superior
technique, especially considering you can use --no-owner if you
really don't want any SET SESSION AUTH commands in there.
regards, tom lane
Tom Lane wrote: > > Yes, but didn't the old code prompt you for passwords, or silently work > > if you had things set to 'trust', while our new code requires > > super-user? > > If you have things set to "trust", you can be superuser, eh? > > A password approach might be workable using ~/.pgpass, but only in a > scenario where (a) a non-superuser has everyone else's passwords in his > ~/.pgpass, and (b) there are no superuser-owned objects in the dump. > Neither of those assumptions hold up to scrutiny. > > In practice I think use-set-session-auth is vastly the superior > technique, especially considering you can use --no-owner if you > really don't want any SET SESSION AUTH commands in there. Agreed. Sorry for the confusion I caused. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Peter Eisentraut <peter_e@gmx.net> writes:
> It had been dicussed on and off for quite some time. This limitation
> should only apply if you create dumps that contain objects owned by more
> than one user. (Does it? I didn't check.)
Yes, because "SET SESSION AUTHORIZATION yourself" is allowed even if
you're not superuser. So for dumps containing only your own objects,
there's really no issue.
regards, tom lane