Re: -Wformat-zero-length
| От | Bruce Momjian |
|---|---|
| Тема | Re: -Wformat-zero-length |
| Дата | |
| Msg-id | 20120808230441.GB24079@momjian.us обсуждение исходный текст |
| Ответ на | Re: -Wformat-zero-length (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: -Wformat-zero-length
|
| Список | pgsql-hackers |
On Wed, Aug 8, 2012 at 06:42:27PM -0400, Tom Lane wrote: > Alvaro Herrera <alvherre@2ndquadrant.com> writes: > > Excerpts from Bruce Momjian's message of mié ago 08 17:15:38 -0400 2012: > >> On Wed, Aug 8, 2012 at 04:23:04PM -0400, Robert Haas wrote: > >>> I think this is one good idea: > >>> http://archives.postgresql.org/message-id/29806.1340655654@sss.pgh.pa.us > > >> If we currently require 14 steps to use pg_upgrade, how would that > >> reduce this number? What failures does it fix? > > > The suggestion by Tom reduces the list by two steps because it doesn't > > need to adjust pg_hba.conf or put it back in the original way > > afterwards. > > Even more to the point, it flat-out eliminates failure modes associated > with somebody connecting to either the old or the new cluster while > pg_upgrade is working. Schemes that involve temporarily hacking > pg_hba.conf can't provide any iron-clad guarantee, because if pg_upgrade > can connect to a postmaster, so can somebody else. We now use a temporary port number, 50432. > The point I think Robert was trying to make is that we need to cut down > not only the complexity of running pg_upgrade, but the number of failure > modes. At least that's how I'd define improvement here. Agreed. Even with these changes, I still see a lot of complexity. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
В списке pgsql-hackers по дате отправления: