| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Bruce Momjian <bruce(at)momjian(dot)us> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Florian Pflug <fgp(at)phlo(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Problem with pg_upgrade (8.4 -> 9.0) due to ALTER DATABASE SET ROLE |
| Date: | 2011-01-07 03:05:02 |
| Message-ID: | 7211.1294369502@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Bruce Momjian <bruce(at)momjian(dot)us> writes:
> We could modify pg_dump to emit RESET AUTHORIZATION in --binary-upgrade
> mode. I am unclear if that might cause some other problems though.
I finally figured out what was really bugging me about that proposal:
it's a one-shot hack for fixing one problem that could arise from
non-default ALTER DATABASE/ALTER ROLE settings. Who's to say there
are not other such issues, either now or in the future?
It occurs to me that a more principled way to deal with this class of
problems would be to delay restoring ALTER DATABASE/ALTER ROLE
settings until after everything else is done. Not sure what the
implementation consequences of that would be. Ideally we'd make
pg_dumpall output work that way in general, not just for pg_upgrade.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 2011-01-07 03:08:28 | Re: Problem with pg_upgrade (8.4 -> 9.0) due to ALTER DATABASE SET ROLE |
| Previous Message | Robert Haas | 2011-01-07 03:02:30 | Re: sepgsql contrib module |