| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Kevin Grittner <kgrittn(at)ymail(dot)com> |
| Cc: | Bruce Momjian <bruce(at)momjian(dot)us>, Andres Freund <andres(at)2ndquadrant(dot)com>, 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-30 23:48:02 |
| Message-ID: | 884.1385855282@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general pgsql-hackers |
Kevin Grittner <kgrittn(at)ymail(dot)com> writes:
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> What is the point of this, given that Kevin fixed pg_dumpall?
>> Don't those fixes take care of the issue?
> 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 be upgraded to a new major release if any
> database within it has that set.
Oh, I had forgotten that pg_upgrade will run additional commands
against the new cluster after restoring the dumpall output.
I guess we do need something like what Bruce did to cover that.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | imagenesis@gmail.com | 2013-11-30 23:54:31 | Use environment variables in postgresql.conf |
| Previous Message | Thomas Kellerer | 2013-11-30 23:27:35 | Re: Full Stored Procedure Support, any time soon ? |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Geoghegan | 2013-11-30 23:56:00 | Re: [PATCH] Report exit code from external recovery commands properly |
| Previous Message | Peter Geoghegan | 2013-11-30 23:34:50 | Re: review - pg_stat_statements |