On Wed, Mar 19, 2014 at 5:28 PM, Kyotaro HORIGUCHI <horiguchi.kyot...@lab.ntt.co.jp> wrote: > Hello, thank you for suggestions. > > The *problematic* operation sequence I saw was performed by > pgsql-RA/Pacemaker. It stops a server already with immediate mode > and starts the Master as a Standby at first, then > promote. Focusing on this situation, there would be reasonable to > reset backup positions. 9.4 canceles backup mode even on > immediate shutdown so the operation causes no problem, but 9.3 > and before are doesn't. Finally, needed amendments per versions > are > > 9.4: Nothing more is needed (but resetting backup mode by > resetxlog is acceptable) > > 9.3: Can be recovered without resetting backup positions in > controlfile. (but smarter with it) > > 9.2: Same to 9.3 > > 9.1: Cannot be recoverd without directly resetting backup > position in controlfile. Resetting feature is needed. > > > At Mon, 17 Mar 2014 15:59:09 +0200, Heikki Linnakangas wrote >> On 03/15/2014 05:59 PM, Fujii Masao wrote: >> > What about adding new option into pg_resetxlog so that we can >> > reset the pg_control's backup start location? Even after we've >> > accidentally entered into the situation that you described, we can >> > exit from that by resetting the backup start location in pg_control. >> > Also this option seems helpful to salvage the data as a last resort >> > from the corrupted backup. >> >> Yeah, seems reasonable. After you run pg_resetxlog, there's no hope >> that the backup end record would arrive any time later. And if it >> does, it won't really do much good after you've reset the WAL. >> >> We probably should just clear out the backup start/stop location >> always when you run pg_resetxlog. Your database is potentially broken >> if you reset the WAL before reaching consistency, but if forcibly do >> that with "pg_resetxlog -f", you've been warned. > > Agreed. Attached patches do that and I could "recover" the > database state with following steps,
Adding new option looks like new feature rather than bug fix. I'm afraid that the backpatch of such a change to 9.3 or before is not acceptable. Regards, -- Fujii Masao -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers