Re: pg_upgrade --logfile option documentation
От | Bruce Momjian |
---|---|
Тема | Re: pg_upgrade --logfile option documentation |
Дата | |
Msg-id | 20120309013348.GE29911@momjian.us обсуждение исходный текст |
Ответ на | Re: pg_upgrade --logfile option documentation (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: pg_upgrade --logfile option documentation
|
Список | pgsql-hackers |
On Thu, Mar 08, 2012 at 10:19:05AM -0500, Tom Lane wrote: > Bruce Momjian <bruce@momjian.us> writes: > > On Thu, Mar 08, 2012 at 08:34:53AM -0500, A.M. wrote: > >> It looks like the patch will overwrite the logs in the current working > >> directory, for example, if pg_upgrade is run twice in the same place. Is > >> that intentional? I had imagined that the logs would have been dumped in > > > Yes. I was afraid that continually appending to a log file on every run > > would be too confusing. I could do only appends, or number the log > > files, that those seemed confusing. > > Use one (set of) files, and always append, but at the beginning of each > run print "\npg_upgrade starting at [timestamp]\n\n". Should make it > reasonably clear, while not losing information. OK, it seems people do care about keeping log files from multiple runs so I went with Tom's idea and have: ----------------------------------------------------------------- pg_upgrade run on Thu Mar 8 19:30:12 2012 ----------------------------------------------------------------- Performing Consistency Checks ----------------------------- Updated patch attached. FYI, in retain mode, these are the files left in the current directory: delete_old_cluster.sh pg_upgrade_dump_all.sql pg_upgrade_dump_db.sql pg_upgrade_dump_globals.sql pg_upgrade_internal.log pg_upgrade_restore.log pg_upgrade_server.log pg_upgrade_utility.log I will address the idea of using /tmp in another email. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
Вложения
В списке pgsql-hackers по дате отправления: