From: | Kevin Grittner <kgrittn(at)ymail(dot)com> |
---|---|
To: | Andres Freund <andres(at)2ndquadrant(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Bruce Momjian <bruce(at)momjian(dot)us>, Karsten Hilbert <Karsten(dot)Hilbert(at)gmx(dot)net>, "Hilbert, Sebastian" <Sebastian(dot)Hilbert(at)gmx(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [GENERAL] pg_upgrade ?deficiency |
Date: | 2013-11-22 22:28:02 |
Message-ID: | 1385159282.72603.YahooMailNeo@web162906.mail.bf1.yahoo.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
Andres Freund <andres(at)2ndquadrant(dot)com> wrote:
> FWIW, I am less than convinced that it is correct for
> pg_dump[all] to emit SET default_transaction_readonly = off;
It doesn't change the database setting, just the connection which
is issuing commands to create global object -- ones that don't
reside in the database we are connected to. As the comment in
pg_dumpall.c says, right above where I added this:
/*
* We used to emit \connect postgres here, but that served no purpose
* other than to break things for installations without a postgres
* database. Everything we're restoring here is a global, so whichever
* database we're connected to at the moment is fine.
*/
> The user might explicitly have set that to prevent against
> somebody restoring into the wrong database or somesuch. Why is it
> our business to override such decisions?
Hmm. If your argument had been that the user intended that the
database be a read-only database, then I would say that your
argument held no water. Any user can choose to make any
transaction (or all subsequent transactions on the connection)
read-write any time they want. The problem with pg_dumpall as it
stands is that it sets the databases to that default and then tries
to load data into them, which fails.
But you have a point regarding adding what I proposed to pg_dump.
The more I think about it, the more I'm inclined to think that
pg_dumpall should insert this right after the \connect to a
database it is going to write to, rather than affecting pg_dump
output at all. That would allow you default protection against
writing pg_dump output to a database that was flagged this way.
You could get around it by connecting interactively with psql,
issuing a SET command, and bringing in dump output with \i from a
text file. If we go this way, would we want options on pg_restore
and/or psql to issue this set when reading in a file (or piped
input)?
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2013-11-22 23:20:38 | Re: [GENERAL] pg_upgrade ?deficiency |
Previous Message | Andres Freund | 2013-11-22 21:58:24 | Re: [GENERAL] pg_upgrade ?deficiency |
From | Date | Subject | |
---|---|---|---|
Next Message | Mike Blackwell | 2013-11-22 22:34:18 | Re: why semicolon after begin is not allowed in postgresql? |
Previous Message | AK | 2013-11-22 22:24:05 | why semicolon after begin is not allowed in postgresql? |