> datafiles from /var/lib/pgsql10/data (db was empty).
Yeah, after further experimentation I saw that pg_upgrade would fail
in a pretty obvious way unless the supposedly-config-only directory
also contains a full set of subdirectories (base, pg_wal, etc).
We could imagine removing that chec
When the cluster was created, we did initdb /var/lib/pgsql10/data, the
storagebox was not available.
Then storagebox was delivered, we copied data folder to storagebox in
/mnt/pgdata/pgdir and changed postgresql.conf. We didn't delete existing
datafiles from /var/lib/pgsql10/data (db was empty)
[ Please keep the mailing list cc'd ]
Alain Bourgeois writes:
> I confirm copyig config to data dir and specifying data dir works
> /usr/pgsql-15/bin/pg_upgrade --check -b /usr/pgsql-10/bin/ -B
> /usr/pgsql-15/bin -d /mnt/pgdata/pgdir -D /mnt/pgdata/pgdirbc15 --check
Hm. On seco
This is probably the source of your problem. IIRC, pg_upgrade
> needs to be pointed at the actual old data directory, not
> PGDATA=/var/lib/pgsql/10/data.
Correct, pg_upgrade use the PGDATANEW and PGDATAOLD env variables for the
cluster data directories.
--
Daniel Gustafsson
Alain Bourgeois writes:
> /usr/lib/systemd/system/postgresql-10.service has
> PGDATA=/var/lib/pgsql/10/data/, /var/lib/pgsql/10/data/postgtresql.conf holds
> data_directory = '/mnt/pgdata/pgdir'
This is probably the source of your problem. IIRC, pg_upgrade
needs to be po
Tried (as postgres)
/usr/pgsql-15/bin/pg_upgrade --check -b /usr/pgsql-10/bin/ -B /usr/pgsql-15/bin
-d /var/lib/pgsql/10/data -D /mnt/pgdata/pgdirbc15 -p5432 -P5455 -Upostgres -v
Running in verbose mode
Performing Consistency Checks
-
Checking cluster versions
.conf is in PGDATA directory (which is not the case
of the old one).
systemctl start postgresql-15-bc works without any problem. It has been stopped
before pg_upgrade --check.
Postgres 10 cannot be stopped, it is a live prod system.
PG Doc comments form writes:
> https://www.postgresql.org/docs/15/pgupgrade.html tells
> "You can use pg_upgrade --check to perform only the checks, even if the old
> server is still running."
I tested this case, and it seems to work for me. pg_upgrade will try
to start a ser
The following documentation comment has been logged on the website:
Page: https://www.postgresql.org/docs/15/pgupgrade.html
Description:
https://www.postgresql.org/docs/15/pgupgrade.html tells
"You can use pg_upgrade --check to perform only the checks, even if the old
server is still runnin
On Wed, Sep 27, 2023 at 09:42:49AM +0200, Daniel Gustafsson wrote:
> > On 26 Sep 2023, at 22:26, Bruce Momjian wrote:
> > On Tue, Sep 26, 2023 at 10:56:27AM -0700, David G. Johnston wrote:
>
> >> I would get rid of any mentions of our old pre-v10 versioning scheme in the
> >> current documentatio
> On 26 Sep 2023, at 22:26, Bruce Momjian wrote:
> On Tue, Sep 26, 2023 at 10:56:27AM -0700, David G. Johnston wrote:
>> I would get rid of any mentions of our old pre-v10 versioning scheme in the
>> current documentation.
For content such as this, a very big +1.
> Good point, how is this attac
on the website:
> >
> > Page: https://www.postgresql.org/docs/16/pgupgrade.html
> > Description:
> >
> > I feel like for readability the pg_upgrade doc should use the same
> > old_version and new_version examples when showing examples throughout
> th
Description:
> >
> > I feel like for readability the pg_upgrade doc should use the same
> > old_version and new_version examples when showing examples throughout the
> > doc page.
> >
> > as an exmaple I'm looking at :
> > https://www.postgresql.org/docs/c
On Mon, Sep 18, 2023 at 08:14:04PM +, PG Doc comments form wrote:
> The following documentation comment has been logged on the website:
>
> Page: https://www.postgresql.org/docs/16/pgupgrade.html
> Description:
>
> I feel like for readability the pg_upgrade doc s
The following documentation comment has been logged on the website:
Page: https://www.postgresql.org/docs/16/pgupgrade.html
Description:
I feel like for readability the pg_upgrade doc should use the same
old_version and new_version examples when showing examples throughout the
doc page.
as an
Thank you Bruce !
On Fri, 15 Jul 2022 at 2:04 AM, Bruce Momjian wrote:
> On Sat, Jul 9, 2022 at 10:38:30PM -0400, Bruce Momjian wrote:
> > > (source: https://www.postgresql.org/docs/devel/pgupgrade.html)
> > >
> > > I'm a new contributor so please forgive me if I'm on the wrong
> track
On Sat, Jul 9, 2022 at 10:38:30PM -0400, Bruce Momjian wrote:
> > (source: https://www.postgresql.org/docs/devel/pgupgrade.html)
> >
> > I'm a new contributor so please forgive me if I'm on the wrong track,
> > but if you follow this step, won't you also be ensuring that replication
>
On Sat, Jun 4, 2022 at 03:08:58PM +0530, Nikhil Shetty wrote:
> Hi Jack,
>
> I followed the same steps multiple times but each time, slot had to be
> recreated.
>
> The slots under directory pg_replslot are not created in the new cluster
> during
> pg_upgrade.
>
>
Hi Jack,
I followed the same steps multiple times but each time, slot had to be
recreated.
The slots under directory pg_replslot are not created in the new cluster
during pg_upgrade.
Thanks and Regards,
Nikhil
On Sat, 4 Jun 2022 at 1:48 AM, Jack DeVries wrote:
> Hi Nikhil,
>
>
Hi Nikhil,
>From the pgupgrade docs:
> 9. Prepare for standby server upgrades
>
> If you are upgrading standby servers using methods outlined in section
> Step 11, verify that the old standby servers are caught up by running
> pg_controldata against the old primary and standby clusters. Verify
>
Hi,
We are upgrading from Postgres 11 to 13. During upgrade we found that the
physical slots on the old cluster are not copied to the new cluster.
This information is not mentioned in the documentation -
https://www.postgresql.org/docs/13/pgupgrade.html
Just thought it would be good to have this
On Tue, 2022-04-05 at 13:10 -0400, Stephen Frost wrote:
> * Robert Haas (robertmh...@gmail.com) wrote:
> On Mon, Jul 26, 2021 at 3:11 PM Stephen Frost wrote:
> > * Laurenz Albe (laurenz.a...@cybertec.at) wrote:
> > > > Thanks for looking at this!
> > >
> > > Sure. Thanks for working on it!
> >
On Tue, 2022-04-05 at 12:38 -0400, Robert Haas wrote:
> Also, let me express my general terror at the idea of anyone actually
> using this procedure.
I did, and I couldn't get it to work with absolute paths, and using
relative paths seemed to me to be more intuitive anyway, hence the patch.
Origi
ve had success using
> it, but I'd really rather we just take it out and put it on a wiki
> somewhere as a "we need a tool that does this stuff" and hope that
> someone finds time to write one.
Well, I think pg_upgrade needs a tool, let alone for standby upgrades,
but 1
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Mon, Jul 26, 2021 at 3:11 PM Stephen Frost wrote:
> > * Laurenz Albe (laurenz.a...@cybertec.at) wrote:
> > > Thanks for looking at this!
> >
> > Sure. Thanks for working on it!
>
> Stephen, do you intend to do something about this pat
On Mon, Jul 26, 2021 at 3:11 PM Stephen Frost wrote:
> * Laurenz Albe (laurenz.a...@cybertec.at) wrote:
> > Thanks for looking at this!
>
> Sure. Thanks for working on it!
Stephen, do you intend to do something about this patch in terms of
getting it committed? You're the only reviewer but haven
On Mon, 2021-07-26 at 15:11 -0400, Stephen Frost wrote:
> > > > > An additional thing that we should really be mentioning is to tell
> > > > > people to go in and TRUNCATE all of their UNLOGGED tables before going
> > > > > through this process, otherwise the rsync will end up spending a bunch
> >
? Wouldn't it make more sense
> > to have something like:
> >
> > g. Configure standby servers
> >
> > Review the prior configuration of the standby servers and set up the
> > same configuration in the newly rsync'd directory.
> >
> > 1.
figuration of the standby servers and set up the
> same configuration in the newly rsync'd directory.
>
> 1. touch /path/to/replica/standby.signal
> 2. Configure restore_command to pull from WAL archive
> 3. For streaming replicas, configure primary_conninfo
Ok, I have modified
nder to create "standby.signal",
> as mentioned in [1].
>
> Yours,
> Laurenz Albe
>
> [1]:
> https://www.postgr.es/m/1a5a1b6e-7bb6-47eb-8443-40222b769...@iris.washington.edu
> From 47b685b700548af06ab08673187bdd1df7236464 Mon Sep 17 00:00:00 2001
> From: Laurenz Albe
> Date: Fri, 16
Albe
[1]:
https://www.postgr.es/m/1a5a1b6e-7bb6-47eb-8443-40222b769...@iris.washington.edu
From 47b685b700548af06ab08673187bdd1df7236464 Mon Sep 17 00:00:00 2001
From: Laurenz Albe
Date: Fri, 16 Jul 2021 07:45:22 +0200
Subject: [PATCH] Improve doc for pg_upgrade and standby servers
Recommend using
On Wed, 2021-05-19 at 10:31 -0400, Stephen Frost wrote:
> * Laurenz Albe (laurenz.a...@cybertec.at) wrote:
> > I revently tried to upgrade a standby following the documentation,
> > but I found it hard to understand, [...]
>
> Haven't had a chance to look at this in depth but improving things here
Greetings,
* Laurenz Albe (laurenz.a...@cybertec.at) wrote:
> I revently tried to upgrade a standby following the documentation,
> but I found it hard to understand, and it took me several tries to
> get it right. This is of course owing to my lack of expertise with
> rsync, but I think the docum
have in real life.
Yours,
Laurenz Albe
From 0ce2de70811ced07eb75215197cbb83cd7a7d2b9 Mon Sep 17 00:00:00 2001
From: Laurenz Albe
Date: Tue, 18 May 2021 19:42:55 +0200
Subject: [PATCH] Improve doc for pg_upgrade and standby servers
Recommend using the --relative option of rsync for clarity
and adapt
On Tue, Dec 8, 2020 at 03:13:30AM +, PG Doc comments form wrote:
> The following documentation comment has been logged on the website:
>
> Page: https://www.postgresql.org/docs/10/pgupgrade.html
> Description:
>
> If we use the following command to upgrade the standby server, then new
> clus
The following documentation comment has been logged on the website:
Page: https://www.postgresql.org/docs/10/pgupgrade.html
Description:
If we use the following command to upgrade the standby server, then new
cluster will create by old_cluster which is not correct.
rsync --archive --delete --hard
On Fri, Jul 26, 2019 at 09:23:28PM +, PG Doc comments form wrote:
> The following documentation comment has been logged on the website:
>
> Page: https://www.postgresql.org/docs/11/pgupgrade.html
> Description:
>
> pg_upgrade seems to assume that the datadir and the conf
The following documentation comment has been logged on the website:
Page: https://www.postgresql.org/docs/11/pgupgrade.html
Description:
pg_upgrade seems to assume that the datadir and the configdir are the same
but on Debian/Ubuntu they are not the same by default (installing from the
postgres
> > of the other options?
> > >
> > >
> > > Looking at it closer I tend to agree, and updated the patch to split this
> > > up in
> > > an attempt to make it a bit clearer for newcomers to pg_upgrade. How
> > > about the
> > >
t one in two -- one
> > for "if you ran it without --link", that should reallyi be listed above
> > any
> > of the other options?
> >
> >
> > Looking at it closer I tend to agree, and updated the patch to split this
> > up in
> > an
allyi be listed above
> any
> of the other options?
>
>
> Looking at it closer I tend to agree, and updated the patch to split this up
> in
> an attempt to make it a bit clearer for newcomers to pg_upgrade. How about the
> attached version?
I agree that current paragra
On Friday, April 5, 2019 2:26 PM, Magnus Hagander wrote:
> On Thu, Apr 4, 2019 at 11:14 PM Daniel Gustafsson wrote:
>
>> Reading the pg_upgrade reference page, I get the feeling that one of the
>> bullets under "Reverting to old cluster" is a bit thin on detail to be
On 4/5/19 8:26 AM, Magnus Hagander wrote:
>
>
> On Thu, Apr 4, 2019 at 11:14 PM Daniel Gustafsson <mailto:dan...@yesql.se>> wrote:
>
> Reading the pg_upgrade reference page, I get the feeling that one of the
> bullets under "Reverting to old cluster"
On Thu, Apr 4, 2019 at 11:14 PM Daniel Gustafsson wrote:
> Reading the pg_upgrade reference page, I get the feeling that one of the
> bullets under "Reverting to old cluster" is a bit thin on detail to be
> helpful
> to newcomers:
>
> "If you ran pg_upgrad
Reading the pg_upgrade reference page, I get the feeling that one of the
bullets under "Reverting to old cluster" is a bit thin on detail to be helpful
to newcomers:
"If you ran pg_upgrade with --link, the data files are shared between the
old and new cluster. If you
The following documentation comment has been logged on the website:
Page: https://www.postgresql.org/docs/11/pgupgrade.html
Description:
"For Windows users, you must be logged into an administrative account, and
then start a shell as the postgres user and set the proper path:
RUNAS /USER:postgre
least by using the EnterpriseDB installer).
You can't start a shell as NetworkService (which seems not to be necessary).
But the owner and permissions of the data directory should be checked and
changed afterwards if necessary.
Another problem (not directly of pg_upgrade) is, that pg_up
On Mon, Jan 29, 2018 at 09:31:46PM -0500, Jim Ryan wrote:
> This looks great. Thanks for working on it.
Done.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+
On Thu, Jan 25, 2018 at 12:46:52PM -0500, Bruce Momjian wrote:
> I propse the attached patch to fix the generic syntax and the example.
> I will backpatch it through 9.5. As you stated, the tablespace example
> is fine.
Done. Thanks for the report.
--
Bruce Momjian http://momjian.u
Thanks for working on this, but wouldn't pg_upgrade be needed from
> 10.1 to
> > 10.2? Aren't those considered major versions, or am I
> misunderstanding?
> >
> > The source of my (and potentially others) confusion is if from 9.1
> to 9.2
> >
On Sat, Jan 27, 2018 at 8:05 AM, Bruce Momjian wrote:
> I decided I needed to be more explicit about the major version numbers
> so I have added major and minor examples for the 9.6.x series and 10.x
> series releases. Patch attached.
>
>
Thanks!
+1
David J.
On Fri, Jan 26, 2018 at 11:35:09AM -0700, David G. Johnston wrote:
> On Friday, January 26, 2018, Jim Ryan wrote:
>
> Hey Bruce,
>
> Thanks for working on this, but wouldn't pg_upgrade be needed from 10.1 to
> 10.2? Aren't those considered major versio
On Friday, January 26, 2018, Jim Ryan wrote:
> Hey Bruce,
>
> Thanks for working on this, but wouldn't pg_upgrade be needed from 10.1 to
> 10.2? Aren't those considered major versions, or am I misunderstanding?
>
> The source of my (and potentially others) confusio
Hey Bruce,
Thanks for working on this, but wouldn't pg_upgrade be needed from 10.1 to
10.2? Aren't those considered major versions, or am I misunderstanding?
The source of my (and potentially others) confusion is if from 9.1 to 9.2
is considered a major version change or not. I
Ah! Thank you. That makes more sense. I think this could still be
confusing for users who did not know about this change and are on 9.x,
because the docs now seemingly imply that they would not need to use
pg_upgrade when moving from 9.x to 9.y, when they actually do. Is
explaining the recent
On Fri, Jan 26, 2018 at 12:04:17PM -0500, Jim Ryan wrote:
> Hey Bruce,
>
> Thanks for working on this, but wouldn't pg_upgrade be needed from 10.1 to
> 10.2? Aren't those considered major versions, or am I misunderstanding?
Uh, it is confusing. We switched in PG 10 fro
s versioning (where 9.5 and
> 9.6 are considered major versions) reads the documentation, it is unclear if
> they need to use pg_upgrade to migrate from 9.5 to 9.6, for example.
>
> The documentation says upgrading "from 9.6.3 to the current major
> release"
>
On Thu, Dec 7, 2017 at 11:28:12AM -0600, Don Seiler wrote:
> In step 10 of the pg_upgrade doc at
> https://www.postgresql.org/docs/9.6/static/
> pgupgrade.html, it uses this example for rsyncing the main $PGDATA dir to the
> standby:
>
>
> rsync --archive --delete --hard-l
ar if
they need to use pg_upgrade to migrate from 9.5 to 9.6, for example.
The documentation says upgrading "from 9.6.3 to the current major
release"
requires pg_upgrade, but not "from 9.6.2 to 9.6.3".
The problem with that language is that the current release of PostgreSQL
In step 10 of the pg_upgrade doc at
https://www.postgresql.org/docs/9.6/static/pgupgrade.html, it uses this
example for rsyncing the main $PGDATA dir to the standby:
rsync --archive --delete --hard-links --size-only --no-inc-recursive
/opt/PostgreSQL/9.5/data \
/opt/PostgreSQL/9.6/data
60 matches
Mail list logo
