> On 15 Dec 2021, at 00:52, Mladen Gogala 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 configu
Micheal,
Thanks for much for the quick response.
> On 15 Dec 2021, at 00:37, Michael Paquier wrote:
>
> On Wed, Dec 15, 2021 at 12:15:27AM -0300, Martín Fernández wrote:
>> The reindex went fine in the primary database and in one of our
>> standby. The other standby that we also operate for som
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 ha
On Wed, Dec 15, 2021 at 12:15:27AM -0300, Martín Fernández wrote:
> The reindex went fine in the primary database and in one of our
> standby. The other standby that we also operate for some reason
> ended up in a state where all transactions were locked by the WAL
> process and the WAL process was
Hello pg hackers!
Today we had to run a `REINDEX table CONCURRENTLY my_table;` in our production
database due to considerable index bloat. We used to deal with this problem in
the past by using pg_repack but we stopped using it because our data
replication tool doesn’t support “re creating” tab
