| From: | "Andrey M(dot) Borodin" <x4mmm(at)yandex-team(dot)ru> |
|---|---|
| To: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
| Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: broken reading on standby (PostgreSQL 16.2) |
| Date: | 2024-04-25 06:52:41 |
| Message-ID: | 273C1399-05DF-40BE-A330-F640582D3AC6@yandex-team.ru |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> On 25 Apr 2024, at 11:12, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> wrote:
>
> yesterday, I had to fix strange issue on standby server
It’s not just broken reading, if this standby is promoted in HA cluster - this would lead to data loss.
Recently I’ve observed some lost heap updates ofter OOM-ing cluster on 14.11. This might be unrelated most probably, but I’ll post a link here, just in case [0]. In February and March we had 3 clusters with similar problem, and this is unusually big number for us in just 2 months.
Can you check LSN of blocks with corrupted tuples with pageinpsect on primary and on standby? I suspect they are frozen on primary, but have usual xmin on standby.
Best regards, Andrey Borodin.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Frédéric Yhuel | 2024-04-25 06:52:50 | Re: New GUC autovacuum_max_threshold ? |
| Previous Message | Pavel Stehule | 2024-04-25 06:12:17 | broken reading on standby (PostgreSQL 16.2) |