Re: query hangs out

On Wed, 2025-05-21 at 12:06 +0300, Антон Глушаков wrote:
> The problem is with only one table.
>
> As a result, I determined that the problem is on page 5 of the table (I made SELECT ctid selections until it hangs).
> Then I tried to delete rows by ctid (5, 0-100) from the table until I found the problematic row.
>
> Content through pageinspect:
> # SELECT * FROM heap_page_items(get_raw_page('"InboxState"', 5)) where lp = 51;
> -[ RECORD 1 ]-------------------------------------------------------------------------------------------------------------------------------------------
> lp          | 51
> lp_off      | 3760
> lp_flags    | 1
> lp_len      | 100
> t_xmin      | 136269917
> t_xmax      | 66664135
> t_field3    | 0
> t_ctid      | (47,13)
> t_infomask2 | 8203
> t_infomask  | 4929
> t_hoff      | 32
> t_bits      | 1111011000000000
> t_oid       |
> t_data      | \x3e8a7c00000000000100000090877a16b4b308dd9460898784c4af2dab692693d29bdf78bcf5153401000000fd55f20f44ec08dd9460f88969b943ab3cd8020000000000

So the tuple is frozen AND updated, with the new version at (47,13). Odd.
What do you see at (47,13)?

> I couldn't delete it in the standard way (delete from "InboxState" where ctid = '(5,51)') - it also hangs.
>
> But I can freeze it through pg_surgery.
>
> # select heap_force_freeze('"InboxState"'::regclass, ARRAY['(5, 51)']::tid[]);
>
> Output after freeze:
> digitalarchive=# SELECT * FROM heap_page_items(get_raw_page('"InboxState"', 5)) where lp = 51;
> -[ RECORD 1 ]-------------------------------------------------------------------------------------------------------------------------------------------
> lp          | 51
> lp_off      | 3760
> lp_flags    | 1
> lp_len      | 100
> t_xmin      | 2
> t_xmax      | 0
> t_field3    | 0
> t_ctid      | (5,51)
> t_infomask2 | 11
> t_infomask  | 2817
> t_hoff      | 32
> t_bits      | 1111011000000000
> t_oid       |
> t_data      | \x3e8a7c00000000000100000090877a16b4b308dd9460898784c4af2dab692693d29bdf78bcf5153401000000fd55f20f44ec08dd9460f88969b943ab3cd8020000000000

Now it is only frozen.

> After that, queries to the table started to work normally.
> I'll note that there are absolutely no errors in the postgres logs, checksums are enabled, there are no errors for them either.

I would still recommend a dump and restore to get rid of the data corruption.

> It seems that this is a bug.

Possible.

Yours,
Laurenz Albe