On Mon, Oct 24, 2016 at 8:10 AM, wrote:
> This was actually introduced some time back, and I am not completely certain
> how it crept into our codebase. I think that at least part of the
> explanation lies in the fact that we are experiencing a fair amount of
> growth in
Hi All,
thank you all, I sincerely appreciate your feedback.
I have done a fair amount of testing on the solution proposed by you all (not
removing backup_label), and it seems to have completely addressed the issue.
This was actually introduced some time back, and I am not completely certain
On Thu, Oct 20, 2016 at 8:21 AM, wrote:
> Version : 9.2.13
You are missing over a year's worth of bug fixes.
https://www.postgresql.org/support/versioning/
> - remove a file called backup_label
On 2016-10-20 22:37:15 +0900, Michael Paquier wrote:
> On Thu, Oct 20, 2016 at 10:21 PM, wrote:
> > - remove a file called backup_label, but I am not certain that this file is
> > in fact there (any more).
>
> It is never a good idea when you are trying to restore from a
On Thu, Oct 20, 2016 at 10:21 PM, wrote:
> Version : 9.2.13
You are largely out of date here. The last minor version available in
the 9.2 series is 9.2.18, meaning that you are missing more than one
year worth of bug fixes.
> - remove a file called backup_label, but
Hi Andres,
thank you very much for your response.
Full details on our postgresql version is:
Name : postgresql-server
Arch : x86_64
Version : 9.2.13
Release : 1.el7_1
Size : 3.8 M
Repo : rhel-7-server-dvd-rpms
Summary : The programs needed to create and run a PostgreSQL server
URL :
Hi All,
we are running many postgresql master/slave setups. The slaves are
initialised from a pg_basebackup from the master and are sync streaming
from the master. When we determine the master has failed, the slave is
promoted. Some time after that, the old master is again initialised with a
Hi,
On 2016-10-18 14:57:52 +0200, fred...@huitfeldt.com wrote:
> we are running many postgresql master/slave setups. The slaves are
> initialised from a pg_basebackup from the master and are sync
> streaming from the master. When we determine the master has failed,
> the slave is promoted. Some
Hi All,
we are running many postgresql master/slave setups. The slaves are initialised
from a pg_basebackup from the master and are sync streaming from the master.
When we determine the master has failed, the slave is promoted. Some time after
that, the old master is again initialised with a