From: | Martín Fernández <fmartin91(at)gmail(dot)com> |
---|---|
To: | Mladen Gogala <gogala(dot)mladen(at)gmail(dot)com> |
Cc: | pgsql-general(at)lists(dot)postgresql(dot)org |
Subject: | Re: Reindex "locked" standby database |
Date: | 2021-12-15 04:20:51 |
Message-ID: | 35C0351B-BB50-413E-9F7C-9BECB8A42752@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
> On 15 Dec 2021, at 00:52, Mladen Gogala <gogala(dot)mladen(at)gmail(dot)com> wrote:
>
> On 12/14/21 22:37, Michael Paquier wrote:
>> You are referring to the startup process that replays WAL, right?
>> Without having an idea about the type of workload your primary and/or
>> standbys are facing, as well as an idea of the configuration you are
>> using on both (hot_standby_feedback for one), I have no direct idea,
>> but that could be a conflict caused by a concurrent vacuum.
>
> Hi Michael,
>
> I am preparing for a standby deployment. I don't have a standby yet and, therefore, I don't have any standby problems. Would it be advisable to turn vacuum off on the standby? Applying WAL will also, in theory, populate the statistics which is also held in the database blocks.
Take this with grain of salt since I’m far from being an expert :) , just trying to help. To my knowledge, assuming you would be running a physical standby, vacuum operations wouldn’t run there, only in the primary. Changes would get propagated via physical replication to your standby (blocks that change due to vacuuming on the primary).
Hope that helps.
>
> Regards
>
> --
> Mladen Gogala
> Database Consultant
> Tel: (347) 321-1217
> https://dbwhisperer.wordpress.com
>
>
>
From | Date | Subject | |
---|---|---|---|
Next Message | Estevan Rech | 2021-12-15 17:45:15 | Best Strategy for Large Number of Images |
Previous Message | Martín Fernández | 2021-12-15 04:10:45 | Re: Reindex "locked" standby database |