From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | live-school support <infos(at)live-school(dot)net> |
Cc: | pgsql-general(at)lists(dot)postgresql(dot)org |
Subject: | Re: Reuse an existing slot with a new initdb |
Date: | 2020-05-14 03:52:34 |
Message-ID: | 20200514035234.GC166343@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Wed, May 13, 2020 at 02:12:45PM -0700, live-school support wrote:
> I didn't recal that it was not possible to create a hot standby with a fresh
> new install and pg_dumpall :(.
>
> only pg_basebackup or an exact copy of the data folder can do it right? is
> the reason technical or else?
When using physical replication, both the primary and standby need to
have the same system ID, and both instances need to share the same
architectures to work properly as data is physically replayed from one
cluster to the other using WAL, which includes for example copies of
on disk relation 8kB pages (ever heard of full_page_writes?).
Like Laurenz, I am not sure what is your problem, what are the errors
PostgreSQL are producing and what you expect from Postgres. If you
could describe clearly step-by-step what you are doing and what you
expect the result would be based on your configuration, we may be able
to help, but it is not really possible to help out without more
details. For example, the first sentence of your first email mentions
the use of replication slots. You may want to explain better where
the slots are used, how they get either dropped and/or recreated, etc.
-
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2020-05-14 03:59:49 | Re: Practical usage of large objects. |
Previous Message | Ron | 2020-05-14 03:05:18 | Re: Practical usage of large objects. |