On Tue, Nov 26, 2013 at 03:25:44PM -0800, Kevin Grittner wrote:
> > doc patch?
>
> Instead of the fix you mean, or with it? I don't see what we would
> change in the docs for the fix; the alternative might be to
> document that pg_dumpall output will fail to restore if any
> database (or the restoring user) has this property set.
a) since pg_dump is not planned to be changed to deal with it a hint in the pg_dump docs would be helpful
I can fully understand the argument that if the dump
does NOT contain a "create database" the restore
should indeed honor the existing database setting.
In case it does contain a "create database" statement
the issue won't exist -- because the database will
need to be gone before the restore.
b) if pg_ugprade is not fixed then a hint in the docs is useful (see below)
> > pg_upgrade probably needs a doc patch too, or a reset like
> > pg_dumpall. pg_upgrade is more like pg_dumpall, so a code patch
> > seems most logical, again, assuming we decide that pg_dumpall is
> > the right place for this reset of default_transaction_read_only.
>
> I don't have much opinion on what the pg_upgrade aspect except,
The situation is this:
naive user:- installs new PG version- upgrades old cluster with one default_read_only database- upgrade fails (or check
fails- latter requires patch)- user asks someone- user unsets default_read_only- upgrades old cluster- upgrade
succeeds-user re-sets default_read_only
careful user:- installs new PG version- reads pg_upgrade docs of new version (requires doc patch)- user unsets
default_read_only-upgrades old cluster- upgrade succeeds- user re-sets default_read_only
I can't for the life of it think of a scenario where
one would go: Oh, I've got a default_read_only
database -- let's NOT upgrade the cluster.
> check. Passing the check but failing during the upgrade would not
> be very user-friendly. Again, I'm not sure that a doc patch is
> needed to say that pg_upgrade works even when this option is set.
> Why would anyone assume otherwise? Why would we list this property
> and not others?
A doc patch is only needed if pg_upgrade does NOT work
when some databases are default_read_only because THAT
is counterintuitive: To the naive user upgrading from
version to version is like "make a copy, perhaps rename
a file or two". It doesn't intuitively suggest a need
for WRITE access to individual databases themselves.
However, if the current behaviour is retained it would
be very useful to document that and also document one
or two ways around it (unsetting, PGOPTIONS, ...).
Karsten
--
GPG key ID E4071346 @ gpg-keyserver.de
E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
