BTW, thanks to all who helped in improving this issue.
Karsten
--
GPG key ID E4071346 @ gpg-keyserver.de
E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On Mon, Dec 02, 2013 at 11:41:10AM -0500, Bruce Momjian wrote:
If there were databases or users with default_transaction_read_only
set in the old cluster, the pg_dumpall run will cause that property
to be set in the new cluster, so what you are saying seems to be
that a cluster can't
On Mon, Dec 02, 2013 at 01:24:18PM -0500, Bruce Momjian wrote:
If there were databases or users with default_transaction_read_only
set in the old cluster, the pg_dumpall run will cause that property
to be set in the new cluster, so what you are saying seems to be
that a
On Sat, Nov 30, 2013 at 03:21:08PM -0800, Kevin Grittner wrote:
If your argument is that you want pg_upgrade to work even if the
user already turned on default_transaction_read_only in the *new*
cluster, I would humbly disagree with that goal, for pretty much
the same reasons I didn't
On Wed, Nov 27, 2013 at 09:22:50PM -0500, Bruce Momjian wrote:
Well, I can understand that, but part of the argument was that
default_transaction_read_only is not part of the database, but rather
just the transaction default:
Karsten wrote:
Maybe I am splitting hairs but setting
On Thu, Nov 28, 2013 at 10:39:18AM -0500, Bruce Momjian wrote:
Well, then we are actually using two different reasons for patching
pg_dumpall and not pg_dump. Your reason is based on the probability of
failure, while Tom/Kevin's reason is that default_transaction_read_only
might be used to
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
On Sat, Nov 23, 2013 at 08:44:42AM -0800, Kevin Grittner wrote:
Here's my problem with that. Here's setup to create what I don't
think is all that weird a setup:
...
The following appears to produce a good backup, since there is no
error:
...
Now we attempt to restore what we thought
On Sat, Nov 23, 2013 at 12:11:56PM -0500, Tom Lane wrote:
I also agree with *not* changing pg_dump, since it is not the charter
of pg_dump to recreate a whole cluster, and the objection about possibly
restoring into a database that was meant to be protected by this setting
seems to have some
On Mon, Mar 10, 2008 at 12:16:52AM -0700, David Fetter wrote:
- Add to TODO: Add SQLSTATE severity to PGconn return status.
Yes, please. I have recently been discussing this with
Andreas, Bernd and Peter at Linuxtage Chemnitz.
In GNUmed we want to be able to distinguish connection
errors due
10 matches
Mail list logo
