On 29/05/15 12:59, Noah Misch wrote:
On Thu, May 28, 2015 at 05:26:56PM +0200, Christoph Berg wrote:
Re: Noah Misch 2015-05-28 <20150528150234.ga4111...@tornado.leadboat.com>
To clarify for the archives, the 2015-05-16 changes did not revert to 9.3 and
earlier behavior. Rather, they standardiz
On Thu, May 28, 2015 at 05:26:56PM +0200, Christoph Berg wrote:
> Re: Noah Misch 2015-05-28 <20150528150234.ga4111...@tornado.leadboat.com>
> > To clarify for the archives, the 2015-05-16 changes did not revert to 9.3
> > and
> > earlier behavior. Rather, they standardized on the
> > {9.0,9.1,9.
Re: Noah Misch 2015-05-28 <20150528150234.ga4111...@tornado.leadboat.com>
> On Thu, May 28, 2015 at 10:20:58AM -0400, Bruce Momjian wrote:
> > On Thu, May 28, 2015 at 08:47:07AM +0100, Simon Riggs wrote:
> > > What we should be saying is that the last timeline doesn't need a history
> > > file.
>
On Thu, May 28, 2015 at 10:20:58AM -0400, Bruce Momjian wrote:
> On Thu, May 28, 2015 at 08:47:07AM +0100, Simon Riggs wrote:
> > What we should be saying is that the last timeline doesn't need a history
> > file.
> > Then no change is needed here.
>
> Yes, that would make a lot more sense than w
On Thu, May 28, 2015 at 10:39:15AM -0400, Noah Misch wrote:
> > > It looks like an upgrade from 9.1.x to 9.3.0 or later has always set the
> > > new
> > > timeline identifier (TLI) to 1. My testing confirms this for an upgrade
> > > from
> > > 9.1.16 to 9.4.1 and for an upgrade from 9.1.16 to 9.
On Thu, May 28, 2015 at 10:18:18AM +0200, Christoph Berg wrote:
> Re: Noah Misch 2015-05-28 <20150528072721.ga4102...@tornado.leadboat.com>
> > > I've just had trouble getting barman to work again after a 9.1->9.4.2
> > > upgrade, and I think part of the problem was that the WAL for this
> > > clus
On Thu, May 28, 2015 at 10:13:14AM +0200, Christoph Berg wrote:
> Re: Bruce Momjian 2015-05-28 <20150527221607.ga7...@momjian.us>
> > Well, if you used pg_dump/pg_restore, you would have had even larger
> > problems as the file names would have matched.
>
> True, but even here it's possible that f
On Thu, May 28, 2015 at 08:47:07AM +0100, Simon Riggs wrote:
> We could have pg_upgrade increment the timeline and allow for missing
> history files, but that doesn't fix problems with non-pg_upgrade
> upgrades, which also should never be sharing WAL files from previous
> major vers
Re: Noah Misch 2015-05-28 <20150528072721.ga4102...@tornado.leadboat.com>
> > I've just had trouble getting barman to work again after a 9.1->9.4.2
> > upgrade, and I think part of the problem was that the WAL for this
> > cluster got reset from timeline 2 to 1, which made barman's incoming
> > WAL
Re: Simon Riggs 2015-05-28
> Hmm, it looks like the change to TimeLine 1 is just a kludge anyway. The
> rule that TimeLine 1 doesn't need a history file is itself a hack.
>
> What we should be saying is that the last timeline doesn't need a history
> file. Then no change is needed here.
IMHO it
Re: Bruce Momjian 2015-05-28 <20150527221607.ga7...@momjian.us>
> Well, if you used pg_dump/pg_restore, you would have had even larger
> problems as the file names would have matched.
True, but even here it's possible that files get overwritten. If you
had a server running on TL 1 for files 000100
On 27 May 2015 at 18:42, Bruce Momjian wrote:
> On Wed, May 27, 2015 at 05:40:09PM +0200, Christoph Berg wrote:
> > commit 4c5e060049a3714dd27b7f4732fe922090edea69
> > Author: Bruce Momjian
> > Date: Sat May 16 00:40:18 2015 -0400
> >
> > pg_upgrade: force timeline 1 in the new cluster
>
On Wed, May 27, 2015 at 05:40:09PM +0200, Christoph Berg wrote:
> commit 4c5e060049a3714dd27b7f4732fe922090edea69
> Author: Bruce Momjian
> Date: Sat May 16 00:40:18 2015 -0400
>
> pg_upgrade: force timeline 1 in the new cluster
>
> Previously, this prevented promoted standby servers
On Wed, May 27, 2015 at 10:06:03PM +0200, Christoph Berg wrote:
> Re: Bruce Momjian 2015-05-27 <20150527174244.gb31...@momjian.us>
> > > In fact, I'm wondering if pg_upgrade shouldn't rather *increase* the
> > > timeline to make sure the archive_command doesn't clobber any files
> > > from the old
Re: Bruce Momjian 2015-05-27 <20150527174244.gb31...@momjian.us>
> > In fact, I'm wondering if pg_upgrade shouldn't rather *increase* the
> > timeline to make sure the archive_command doesn't clobber any files
> > from the old cluster when reused in the new cluster?
> >
> > https://bugs.debian.org
On Wed, May 27, 2015 at 05:40:09PM +0200, Christoph Berg wrote:
> commit 4c5e060049a3714dd27b7f4732fe922090edea69
> Author: Bruce Momjian
> Date: Sat May 16 00:40:18 2015 -0400
>
> pg_upgrade: force timeline 1 in the new cluster
>
> Previously, this prevented promoted standby servers
commit 4c5e060049a3714dd27b7f4732fe922090edea69
Author: Bruce Momjian
Date: Sat May 16 00:40:18 2015 -0400
pg_upgrade: force timeline 1 in the new cluster
Previously, this prevented promoted standby servers from being upgraded
because of a missing WAL history file. (Timeline 1 do
17 matches
Mail list logo
