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
Takahiro Itagaki itagaki.takah...@oss.ntt.co.jp writes:
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?
The proposed patch seems quite ugly to me; not only the messy coding,
but the fact that it might return
On Thu, Feb 4, 2010 at 4:28 PM, Fujii Masao masao.fu...@gmail.com wrote:
Sorry for resurrecting an old argument.
http://archives.postgresql.org/message-id/200812051441.mb5efg1m007...@wwwmaster.postgresql.org
I got the complaint about this behavior of the current pg_stop_backup()
in this
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
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 0002001000FE)
On Fri, Feb 5, 2010 at 9:08 AM, Takahiro Itagaki
itagaki.takah...@oss.ntt.co.jp wrote:
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
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.
SELECT pg_start_backup('filename');
pg_start_backup
-
10/FE1E2BAC
