We first noticed the issue after running the generated analyze script, in
subsequent tests it shows up before the analyze though.
Ran thru the process as a test monday night and it worked. This time however,
I deleted the complete 9.2 data directory before running our rsync scripts that
refre
On Mon, Aug 15, 2016 at 3:56 PM, Bruce Momjian wrote:
> On Mon, Aug 15, 2016 at 12:18:04PM -0700, Adrian Klaver wrote:
> > https://www.postgresql.org/docs/9.5/static/pgupgrade.html
> >
> > "Obviously, no one should be accessing the clusters during the upgrade.
> > pg_upgrade defaults to running s
On Mon, Aug 15, 2016 at 12:18:04PM -0700, Adrian Klaver wrote:
> https://www.postgresql.org/docs/9.5/static/pgupgrade.html
>
> "Obviously, no one should be accessing the clusters during the upgrade.
> pg_upgrade defaults to running servers on port 50432 to avoid unintended
> client connections. Yo
On 08/15/2016 11:52 AM, Pete Fuller wrote:
Same chips, same model Dell Poweredge actually. The process is pretty
much the same between the local and offsite replicas, we have a
home-brew script that runs an rsync from the master to the replica. On
the local replica, it then takes the machine ou
Same chips, same model Dell Poweredge actually. The process is pretty much the
same between the local and offsite replicas, we have a home-brew script that
runs an rsync from the master to the replica. On the local replica, it then
takes the machine out of pacemaker standby, on the offsite rep
On 08/15/2016 08:04 AM, Pete Fuller wrote:
We have not found any obvious differences, other than the size of the
databases (~ 100 gig on the testing site vs 400 Gig in production). In
fact, the upgrade path seems to work with our production db when testing
on our offsite replica that lives in ou
Hello,
On Mon, 2016-08-15 at 08:45 -0700, Adrian Klaver wrote:
> On 08/15/2016 08:04 AM, Pete Fuller wrote:
> >
> > We have not found any obvious differences, other than the size of
> > the
> > databases (~ 100 gig on the testing site vs 400 Gig in
> > production). In
> > fact, the upgrade path s
On 08/15/2016 08:04 AM, Pete Fuller wrote:
We have not found any obvious differences, other than the size of the
databases (~ 100 gig on the testing site vs 400 Gig in production). In
fact, the upgrade path seems to work with our production db when testing
on our offsite replica that lives in ou
We have not found any obvious differences, other than the size of the databases
(~ 100 gig on the testing site vs 400 Gig in production). In fact, the upgrade
path seems to work with our production db when testing on our offsite replica
that lives in our backup datacenter, near identical hardwa
On 08/15/2016 07:40 AM, Pete Fuller wrote:
Directories are correct. We do not utilize tablespaces.
Anything obviously different in the setup between your production
servers and the testing and development clusters?
On Aug 15, 2016, at 10:06 AM, Adrian Klaver mailto:adrian.kla...@aklav
Directories are correct. We do not utilize tablespaces.
> On Aug 15, 2016, at 10:06 AM, Adrian Klaver wrote:
>
> On 08/15/2016 06:20 AM, Pete Fuller wrote:
>> Hello all,
>>
>> We are attempting to upgrade a production 9.2 postgres cluster to 9.5. The
>> server is running Centos 7 with the
On 08/15/2016 06:20 AM, Pete Fuller wrote:
Hello all,
We are attempting to upgrade a production 9.2 postgres cluster to 9.5. The
server is running Centos 7 with the Centos version - currently 9.2.15 We are
installing the postgresql provided rpm of postgresql9.5 from the postgresql
repo, curre
Hello all,
We are attempting to upgrade a production 9.2 postgres cluster to 9.5. The
server is running Centos 7 with the Centos version - currently 9.2.15 We are
installing the postgresql provided rpm of postgresql9.5 from the postgresql
repo, currently 9.5.4. In testing and on our development
13 matches
Mail list logo
