Re: query hangs out
| От | Антон Глушаков |
|---|---|
| Тема | Re: query hangs out |
| Дата | |
| Msg-id | CAHnOmadXtVfft-uo9ZJcTP20LfbXViLh1dSZixXzer73Xo1GKg@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: query hangs out (Антон Глушаков <a.glushakov86@gmail.com>) |
| Список | pgsql-admin |
Thank you.
I have investigated the logs to find the cause.
The only thing I found is that the problem started after a failover (we use patroni with synchronous replication).
The problem is unlikely on the hardware level, since we use a private cloud with enterprise-level hardware, and the checksum verification in postgres did not find any problems.
If this is a bug in postgres, and hackers are willing to investigate the problem, I can provide an archive with pgdata
I have investigated the logs to find the cause.
The only thing I found is that the problem started after a failover (we use patroni with synchronous replication).
The problem is unlikely on the hardware level, since we use a private cloud with enterprise-level hardware, and the checksum verification in postgres did not find any problems.
If this is a bug in postgres, and hackers are willing to investigate the problem, I can provide an archive with pgdata
ср, 21 мая 2025 г. в 18:09, Laurenz Albe <laurenz.albe@cybertec.at>:
On Wed, 2025-05-21 at 16:27 +0300, Антон Глушаков wrote:
> > What do you see at (47,13)?
>
> I have restored the data before the freeze, here is the content (47.13)
> SELECT * FROM heap_page_items(get_raw_page('"InboxState"', 47)) where lp = 13;
> -[ RECORD 1 ]-------------------------------------------------------------------------------------------------------------------------------------------
> lp | 13
> lp_off | 4632
> lp_flags | 1
> lp_len | 100
> t_xmin | 136385644
> t_xmax | 136385520
> t_field3 | 0
> t_ctid | (47,13)
> t_infomask2 | 11
> t_infomask | 8337
> t_hoff | 32
> t_bits | 1111011000000000
> t_oid |
> t_data | \x3e8a7c00000000000100000090877a16b4b308dd9460898784c4af2dab692693d29bdf78bcf5153401000000ad43d6a5273608dd947a749769b943ab3cd8020001000000
That tuple should be visible.
So I'd say you should killed the other tuple with heap_force_kill().
Yours,
Laurenz Albe
В списке pgsql-admin по дате отправления: