I'd like to apply the patch to HEAD and previous releases because the issue seems to be a bug in the core. Any comments or objections?
Some users actually use STOP WAL LOCATION in their backup script, and they've countered the bug with 1/256 probability in recent days. Fujii Masao <masao.fu...@gmail.com> wrote: > On Fri, Feb 5, 2010 at 9:08 AM, Takahiro Itagaki > <itagaki.takah...@oss.ntt.co.jp> wrote: > > > > Fujii Masao <masao.fu...@gmail.com> wrote: > > > >> On Fri, Dec 5, 2008 at 11:41 PM, Randy Isbell <jisb...@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, --- Takahiro Itagaki NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
