Re: BUG #4566: pg_stop_backup() reports incorrect STOP WAL LOCATION
От | Heikki Linnakangas |
---|---|
Тема | Re: BUG #4566: pg_stop_backup() reports incorrect STOP WAL LOCATION |
Дата | |
Msg-id | 496F5502.4020907@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: BUG #4566: pg_stop_backup() reports incorrect STOP WAL LOCATION ("Fujii Masao" <masao.fujii@gmail.com>) |
Ответы |
Re: BUG #4566: pg_stop_backup() reports incorrect STOP WAL LOCATION
Re: BUG #4566: pg_stop_backup() reports incorrect STOP WAL LOCATION |
Список | pgsql-bugs |
Fujii Masao wrote: > On Thu, Jan 15, 2009 at 9:09 PM, Heikki Linnakangas > <heikki.linnakangas@enterprisedb.com> wrote: >> 1. The proposed patch would remove the "+ 1". Seems like an unnecessary API >> change, and I don't recall any reason why the new definition would be >> better. > > My patch doesn't change the return value of pg_stop_backup(), it's still > the same as the return value of pg_switch_xlog(). Oh, ok. > Only a part of backup > history file (the file name including stop wal location) is changed. > Currently, the file name is wrong if stop wal location indicates a boundary > byte. This would confuse the user, I think. Hmm, I guess that would make it less confusing. Seems quite dangerous to change the meaning now, however :-(. A program (or person) that knows its current meaning would currently wait for STOP WAL filename - 1 file to be archived. If we change the meaning, the same program would determine that the backup is safe, even if the last xlog file hasn't yet been archived. So I think this is not back-portable. Should we change it in HEAD? I'm leaning towards no, on the grounds that tools/people would then have to know the version it's dealing with to interpret the value correctly, and because pg_stop_backup() now waits for the last xlog file to be archived before returning, there's little need to look at that file. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
В списке pgsql-bugs по дате отправления: