Re: Re: [BUGS] BUG #4566: pg_stop_backup() reports incorrect STOP WAL LOCATION
От | Fujii Masao |
---|---|
Тема | Re: Re: [BUGS] BUG #4566: pg_stop_backup() reports incorrect STOP WAL LOCATION |
Дата | |
Msg-id | 3f0b79eb1002152119m2be4a818x4b72172d27892f@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Re: [BUGS] BUG #4566: pg_stop_backup() reports incorrect STOP WAL LOCATION (Takahiro Itagaki <itagaki.takahiro@oss.ntt.co.jp>) |
Ответы |
Re: Re: [BUGS] BUG #4566: pg_stop_backup() reports incorrect STOP WAL LOCATION
|
Список | pgsql-hackers |
On Fri, Feb 5, 2010 at 9:08 AM, Takahiro Itagaki <itagaki.takahiro@oss.ntt.co.jp> wrote: > > Fujii Masao <masao.fujii@gmail.com> wrote: > >> On Fri, Dec 5, 2008 at 11:41 PM, Randy Isbell <jisbell@cisco.com> wrote: >> > An inconsistency exists between the segment name reported by >> > pg_stop_backup() and the actual WAL file name. >> > >> > START WAL LOCATION: 10/FE1E2BAC (file 0000000200000010000000FE) >> > STOP WAL LOCATION: 10/FF000000 (file 0000000200000010000000FF) > >> But it was rejected because its change might break the existing app. > > It might break existing applications if it returns "FE" instead of "FF", > but never-used filename surprises users. (IMO, the existing apps probably > crash if "FF" returned, i.e, 1/256 of the time.) > > Should it return the *next* reasonable log filename instead of "FF"? > For example, 000000020000002000000000 for the above case. Here is the patch that avoids a nonexistent file name, according to Itagaki-san's suggestion. If we are crossing a logid boundary, the next reasonable file name is used instead of a nonexistent one. Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center
Вложения
В списке pgsql-hackers по дате отправления: