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
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
On Wed, May 27, 2015 at 05:40:09PM +0200, Christoph Berg wrote:
commit 4c5e060049a3714dd27b7f4732fe922090edea69
Author: Bruce Momjian br...@momjian.us
Date: Sat May 16 00:40:18 2015 -0400
pg_upgrade: force timeline 1 in the new cluster
Previously, this prevented promoted
On 27 May 2015 at 18:42, Bruce Momjian br...@momjian.us wrote:
On Wed, May 27, 2015 at 05:40:09PM +0200, Christoph Berg wrote:
commit 4c5e060049a3714dd27b7f4732fe922090edea69
Author: Bruce Momjian br...@momjian.us
Date: Sat May 16 00:40:18 2015 -0400
pg_upgrade: force timeline 1
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
WALs
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
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 files get
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
cluster got
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 what we
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.4.2, so I
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.
Then no
commit 4c5e060049a3714dd27b7f4732fe922090edea69
Author: Bruce Momjian br...@momjian.us
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
On Wed, May 27, 2015 at 05:40:09PM +0200, Christoph Berg wrote:
commit 4c5e060049a3714dd27b7f4732fe922090edea69
Author: Bruce Momjian br...@momjian.us
Date: Sat May 16 00:40:18 2015 -0400
pg_upgrade: force timeline 1 in the new cluster
Previously, this prevented promoted
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/786993
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 cluster
15 matches
Mail list logo
