Skip site navigation (1) Skip section navigation (2)

Re: Re: [BUGS] BUG #4566: pg_stop_backup() reports incorrect STOP WAL LOCATION

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Takahiro Itagaki <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
Subject: Re: Re: [BUGS] BUG #4566: pg_stop_backup() reports incorrect STOP WAL LOCATION
Date: 2010-02-17 17:07:34
Message-ID: 28369.1266426454@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-bugspgsql-docspgsql-hackers
Takahiro Itagaki <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)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 either the segment containing the
XLOG_BACKUP_END record or the next one.

I think an appropriate fix might just be s/XLByteToSeg/XLByteToPrevSeg/,
so that the result is always the segment containing the XLOG_BACKUP_END
record even when the record ends exactly at a segment boundary.

			regards, tom lane

In response to

pgsql-docs by date

Next:From: Greg SmithDate: 2010-02-18 08:11:21
Subject: Hot Standby documentation updates
Previous:From: Takahiro ItagakiDate: 2010-02-17 08:43:19
Subject: Re: Re: [BUGS] BUG #4566: pg_stop_backup() reports incorrect STOP WAL LOCATION

pgsql-hackers by date

Next:From: Peter EisentrautDate: 2010-02-17 17:39:12
Subject: Re: codlin_month is up and complain - PL/Python crash
Previous:From: Tom LaneDate: 2010-02-17 16:26:00
Subject: Re: codlin_month is up and complain - PL/Python crash

pgsql-bugs by date

Next:From: Chris TraversDate: 2010-02-17 17:41:29
Subject: Re: BUG #5331: Integer overflow in tmie counter
Previous:From: Sivaguru SankaridurgDate: 2010-02-17 16:10:20
Subject: Re: BUG #5332: Installation weirdness

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group