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 though
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 so
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 res
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 t
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 t
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 did
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 clu
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
> >
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:
http://www.postgresql.org/mail
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
