Re: [HACKERS] Patch to implement pg_current_logfile() function
От | Michael Paquier |
---|---|
Тема | Re: [HACKERS] Patch to implement pg_current_logfile() function |
Дата | |
Msg-id | CAB7nPqTp-HHrZ8B3qLUKXapzQhYxqVzLqei1P952+=e0nuFm7g@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] Patch to implement pg_current_logfile() function (Kevin Grittner <kgrittn@gmail.com>) |
Список | pgsql-hackers |
On Sat, Jan 14, 2017 at 1:43 AM, Kevin Grittner <kgrittn@gmail.com> wrote: > On Fri, Jan 13, 2017 at 7:09 AM, Michael Paquier > <michael.paquier@gmail.com> wrote: >> There is no real harm in including current_logfiles in base >> backups, but that's really in the same bag as postmaster.opts or >> postmaster.pid, particularly if the log file name has a >> timestamp. > > I'm going to dispute that -- if postmaster.opts and postmaster.pid > are present when you restore, it takes away a level of insurance > against restoring a corrupted image of the database without knowing > it. In particular, if the backup_label file is deleted (which > happens with alarmingly frequency), the startup code may think it > is dealing with a cluster that crashed rather than with a restore > of a backup. This often leads to corruption (anything from > "database can't start" to subtle index corruption that isn't > noticed for months). The presence of log files from the time of > the backup do not present a similar hazard. > > So while I agree that there is no harm in including > current_logfiles in base backups, I object to the comparisons to > the more dangerous files. Good point. -- Michael
В списке pgsql-hackers по дате отправления: