Pravdepodobne poškodený záznam v tabuľke

[Emil J.]

Dobrý deň,

   používam PostgreSQL v16.13-3 pod Windows.

Som absolútny amatér čo sa týka správy PostgreSQL. Viem si spraviť čo potrebujem, ale v oblasti údržby, opravy a nastavenia som nula oproti tým, ktorí tu diskutujú.

Môj problém:

   Mám v DB jednoduchú tabuľku, ktorá má 362 záznamov a pravdepodobne jeden záznam je problémový alebo poškodený.

Keď dám toto:

UPDATE     schema.tb_tabulka

SET        hodnota = hodnota + 1

WHERE      (id_zaznam = 282);

alebo:

DELETE     schema.tb_tabulka

WHERE      (id_zaznam = 282);

Tak mi client zamrzne (môžem čakať aj 5 minút) tak, že ho musím v správcovi úloh natvrdo zrušiť.

Po zavolaní UPDATE alebo DELETE ho vidím v DB ako zamknutý. 

Viem ho odomknúť cez pg_cancel_backend (viac tu), ale keď spravím tú istú akciu (DELETE / UPDATE) znova sa zamkne.

1. Čo je to vlastne za chyba ?

Poškodená tabuľka ?

2. Čo s tým ?

3. Má PostgreSQL nejaký tool, kde by vedel skontrolovať integritu, prípadne by vedel opraviť automaticky poškodené veci ?

V tomto som úplný amatér.

Ďakujem za radu.

Emil Jablonský

[Antonin Houska]

Emil J. <eak...@gmail.com> wrote:

> Môj problém:
> Mám v DB jednoduchú tabuľku, ktorá má 362 záznamov a pravdepodobne jeden záznam je problémový alebo poškodený.
> Keď dám toto:
>
> UPDATE schema.tb_tabulka
> SET hodnota = hodnota + 1
> WHERE (id_zaznam = 282);
>
> alebo:
>
> DELETE schema.tb_tabulka
> WHERE (id_zaznam = 282);
>
> Tak mi client zamrzne (môžem čakať aj 5 minút) tak, že ho musím v správcovi úloh natvrdo zrušiť.
> Po zavolaní UPDATE alebo DELETE ho vidím v DB ako zamknutý.
> Viem ho odomknúť cez pg_cancel_backend (viac tu), ale keď spravím tú istú akciu (DELETE / UPDATE) znova sa zamkne.
>
> 1. Čo je to vlastne za chyba ?
> Poškodená tabuľka ?

Možná tabulka, ale možná jen index.

> 2. Čo s tým ?

V případě poškozeného indexu REINDEX TABLE.

> 3. Má PostgreSQL nejaký tool, kde by vedel skontrolovať integritu, prípadne by vedel opraviť automaticky poškodené veci ?

https://www.postgresql.org/docs/current/amcheck.html

(Jen kontrola, žádné opravy.)

--
Antonín Houska
www.melesmeles.cz

[Emil J.]

Je tam pravdepodobne niečo poškodené.

REINDEX TABLE - zamrzne.

DROP TABLE - zamrzne.

RENAME TABLE - zamrzne.

Keď dám upraviť hociktorý iný záznam: všetko OK.

Len ten jeden záznam má problém a neviem ho vyhodiť, ani tabuľku vyhodiť, ani tabuľku premenovať - v podstate nič.

Idem skúsiť amcheck.

--
Tuto zprávu jste obdrželi, protože jste přihlášeni k odběru skupiny PostgreSQL-cz ve Skupinách Google.
Chcete-li zrušit odběr skupiny a přestat dostávat e‑maily ze skupiny, zašlete e-mail na adresu postgresql-c...@googlegroups.com.
Tuto diskuzi najdete na adrese https://groups.google.com/d/msgid/postgresql-cz/130306.1778664135%40localhost.

[Pavel Stehule]

st 13. 5. 2026 v 11:05 odesílatel Emil J. <eak...@gmail.com> napsal:

Dobrý deň,

   používam PostgreSQL v16.13-3 pod Windows.

Som absolútny amatér čo sa týka správy PostgreSQL. Viem si spraviť čo potrebujem, ale v oblasti údržby, opravy a nastavenia som nula oproti tým, ktorí tu diskutujú.

muzete napsat jak je ta tabulka je velka, a jak jsou velke indexy na disku?

ulozil bych si velikosti a zkusil bych VACUUM FULL, a znova bych zkontroloval velikosti tabulek

tohle vypada, ze a) mate brutalne bloatnutou tabulku, pak by z nejakeho duvodu asi nefungovalo autovacuum - nemate nejake chyby v logu postgresu?

b) neco co jsem nikdy nevidel - mozna cyklus v indexu

c) problem nekde jinde - neco vam muze blokovat systemove tabulky, a pak by bylo blokovano i vacuum, a mohlo by dojit k tomu bloatu

tohle je hodne divne - nemate na pozadi nejakou aplikaci, ktera vam neco zamyka v databazi? Mozna bych si vypsal, hiearchii zamku, na co se vlastne ceka

https://wiki.postgresql.org/wiki/Lock_Monitoring

Tohle je nejaka divocina - vetsinou poskozeny zaznam crashuje cteni, ale neblokuje a nezpusobuje zamky

 

Môj problém:

   Mám v DB jednoduchú tabuľku, ktorá má 362 záznamov a pravdepodobne jeden záznam je problémový alebo poškodený.

Keď dám toto:

UPDATE     schema.tb_tabulka

SET        hodnota = hodnota + 1

WHERE      (id_zaznam = 282);

alebo:

DELETE     schema.tb_tabulka

WHERE      (id_zaznam = 282);

Tak mi client zamrzne (môžem čakať aj 5 minút) tak, že ho musím v správcovi úloh natvrdo zrušiť.

Po zavolaní UPDATE alebo DELETE ho vidím v DB ako zamknutý. 

Viem ho odomknúť cez pg_cancel_backend (viac tu), ale keď spravím tú istú akciu (DELETE / UPDATE) znova sa zamkne.

1. Čo je to vlastne za chyba ?

Poškodená tabuľka ?

2. Čo s tým ?

3. Má PostgreSQL nejaký tool, kde by vedel skontrolovať integritu, prípadne by vedel opraviť automaticky poškodené veci ?

V tomto som úplný amatér.

Ďakujem za radu.

Emil Jablonský

--
Tuto zprávu jste obdrželi, protože jste přihlášeni k odběru skupiny „PostgreSQL-cz“ ve Skupinách Google.
Chcete-li zrušit odběr skupiny a přestat dostávat e‑maily ze skupiny, zašlete e-mail na adresu postgresql-c...@googlegroups.com.

Tuto diskuzi najdete na adrese https://groups.google.com/d/msgid/postgresql-cz/CAEE__4xek8AkfXRkdXKKVJuLqYO4FsKEpGS5fjnZknxad5urXg%40mail.gmail.com.

[Pavel Stehule]

st 13. 5. 2026 v 11:33 odesílatel Emil J. <eak...@gmail.com> napsal:

Je tam pravdepodobne niečo poškodené.

REINDEX TABLE - zamrzne.

DROP TABLE - zamrzne.

RENAME TABLE - zamrzne.

tohle vypada na zamknute systemove tabulky

 

Tuto diskuzi najdete na adrese https://groups.google.com/d/msgid/postgresql-cz/CAEE__4zsGi%2BimSaE9M7xxG8E7D3dS%3DQY%3DjbtSYBT3aAvW-PYeA%40mail.gmail.com.

[Emil J.]

Lock Monitoring zobrazil tabulku bez záznamov (ešte v čase keď UPDATE nefungovalo).

Ten záznam sa momentálne tvári ako opravený. Podarilo sa mi spraviť na ňom UPDATE, aj REINDEX tabuľky.

Neviem ako k tej "samooprave" došlo, lebo s tým bojujem už niekoľko hodín a nič mi doposiaľ nefungovalo.

Je možné, že ten záznam/tabuľku "držal" nejaký klient ? 

Spravil som pg_cancel_backend() na všetky pid-y, ktoré boli spojené so zamknutím tej tabuľky, tak nerozumiem tomu.

Aj napriek tomu nebolo možné záznam vymazať, ani updatovať. Ale len ten jeden, ostatné boli OK.

Teraz je to OK aj pre ten problémový záznam - nechápem.

Neviem ako sa to stalo, ani ako sa to opravilo.

Pozerám v logu či niečo podozrivé nenájdem, ale nič zvláštne tam nevidím.

Predpokladám, že toto je ukončenie klienta v Správcovi úloh vo Windows:

2026-05-13 08:36:13 CEST ERROR:  canceling statement due to user request
2026-05-13 08:36:13 CEST CONTEXT:  SQL statement "UPDATE is8.tb_pouzivatelia ...

Takých je tam kopec za sebou ako som skúšal UPDATE, DELETE, REINDEX, DROP TABLE a podobne.

Medzi týmito záznamami nie je žiadny ERROR ani nič podozrivé.

Nechápem.

Tá tabuľka má už niekoľko rokov a nikdy s ňou nebol žiadny problém. Len za posledné 3 dni sa ojedinele zamkne práve tento záznam.

Budem to naďalej sledovať.

Príčinu ani riešenie tohoto problému nepoznám.

Zatiaľ ďakujem za pomoc.

PS: Ten postgresql musí byť geniálny, keď ten problém vyriešil za mňa a bezomňa. :-)

Za vyše 20 rokov používania zatiaľ naň nedám dopustiť.

Tuto diskuzi najdete na adrese https://groups.google.com/d/msgid/postgresql-cz/CAFj8pRBOLAto1%3Dm%2BOUnvFHymtbaivG7xfQgBzpgh18w8Mj1m2A%40mail.gmail.com.

[David Turoň]

Ahoj, 

si myslim, ze tam visel nekde klient se stavem state = "idle in transaction", ktery zacal transakci, zaznam updatnul ci smazal a z nejakeho duvodu visi ... ceka na neco ..., ostatni jen delaly frontu jak dopadne tento ...

resil by to treshold na nejakou rozumnou hodnotu pro idle in transaction timeout..., ale aplikace se musi nejak vyporadat s pripadnym padem a opakovat operaci ...

SET idle_in_transaction_session_timeout TO '1min';

bud globalne, nebo pro tu roli ALTER ROLE xyz SET ....

David

st 13. 5. 2026 v 13:02 odesílatel Emil J. <eak...@gmail.com> napsal:

Tuto diskuzi najdete na adrese https://groups.google.com/d/msgid/postgresql-cz/CAEE__4yXGiAuYwkWcY5Zo5OrfZ-7bfz-ETnHGWHCYbUX7WRzpA%40mail.gmail.com.

[Pavel Stehule]

st 13. 5. 2026 v 13:02 odesílatel Emil J. <eak...@gmail.com> napsal:

Lock Monitoring zobrazil tabulku bez záznamov (ešte v čase keď UPDATE nefungovalo).

Ten záznam sa momentálne tvári ako opravený. Podarilo sa mi spraviť na ňom UPDATE, aj REINDEX tabuľky.

Neviem ako k tej "samooprave" došlo, lebo s tým bojujem už niekoľko hodín a nič mi doposiaľ nefungovalo.

Je možné, že ten záznam/tabuľku "držal" nejaký klient ? 

Spravil som pg_cancel_backend() na všetky pid-y, ktoré boli spojené so zamknutím tej tabuľky, tak nerozumiem tomu.

Aj napriek tomu nebolo možné záznam vymazať, ani updatovať. Ale len ten jeden, ostatné boli OK.

Teraz je to OK aj pre ten problémový záznam - nechápem.

Neviem ako sa to stalo, ani ako sa to opravilo.

Pozerám v logu či niečo podozrivé nenájdem, ale nič zvláštne tam nevidím.

Predpokladám, že toto je ukončenie klienta v Správcovi úloh vo Windows:

2026-05-13 08:36:13 CEST ERROR:  canceling statement due to user request
2026-05-13 08:36:13 CEST CONTEXT:  SQL statement "UPDATE is8.tb_pouzivatelia ...

Takých je tam kopec za sebou ako som skúšal UPDATE, DELETE, REINDEX, DROP TABLE a podobne.

Medzi týmito záznamami nie je žiadny ERROR ani nič podozrivé.

Nechápem.

Tá tabuľka má už niekoľko rokov a nikdy s ňou nebol žiadny problém. Len za posledné 3 dni sa ojedinele zamkne práve tento záznam.

Budem to naďalej sledovať.

Príčinu ani riešenie tohoto problému nepoznám.

Zatiaľ ďakujem za pomoc.

PS: Ten postgresql musí byť geniálny, keď ten problém vyriešil za mňa a bezomňa. :-)

Za vyše 20 rokov používania zatiaľ naň nedám dopustiť.

:-)

kdyz se takhle neco samo opravi, tak to muze byt jedine zamkem - ale co ten zamek drzelo a proc - to muze byt 100 duvodu - navic jste na windows, takze tam jeste muzou delat brikule antiviry a defenfry 

Tuto diskuzi najdete na adrese https://groups.google.com/d/msgid/postgresql-cz/CAEE__4yXGiAuYwkWcY5Zo5OrfZ-7bfz-ETnHGWHCYbUX7WRzpA%40mail.gmail.com.

[Emil J.]

Myslím, že som na to prišiel. Držal to jeden klient (aplikácia), ktorý neukončil transakciu.

Až keď ho dotyčný človek ukončil (zavrel aplikáciu), tak potom prebehlo všetko čo viselo.

Chyba bola v tom klientovi (aplikácii). Klient je stará aplikácia napísaná v C++ Buildery, kde komponenta ktorá sa pripája na postgres má možnosť: AutoCommit a tá nebola zaškrtnutá. Takže v podstate všetko čo šlo cez tohoto klienta ostalo visieť a zamklo to aj pre ostatných.

Človek pridal záznamy do databázy a keď som pozrel v databáze, tak tam nič nebolo a pritom on ich videl v aplikácii v tabuľke.

Až keď zavrel aplikáciu, tak všetko naskákalo do tabuliek.

Dúfam, že ten autocommit bolo jediné čo to spôsobovalo.

Tuto diskuzi najdete na adrese https://groups.google.com/d/msgid/postgresql-cz/CAFj8pRC0n1-3aOwjgWdGxGig3YoNpbqnyWfR5jhia0g-mxNx1g%40mail.gmail.com.

[Pavel Stehule]

st 13. 5. 2026 v 15:11 odesílatel Emil J. <eak...@gmail.com> napsal:

Myslím, že som na to prišiel. Držal to jeden klient (aplikácia), ktorý neukončil transakciu.

Až keď ho dotyčný človek ukončil (zavrel aplikáciu), tak potom prebehlo všetko čo viselo.

Chyba bola v tom klientovi (aplikácii). Klient je stará aplikácia napísaná v C++ Buildery, kde komponenta ktorá sa pripája na postgres má možnosť: AutoCommit a tá nebola zaškrtnutá. Takže v podstate všetko čo šlo cez tohoto klienta ostalo visieť a zamklo to aj pre ostatných.

Človek pridal záznamy do databázy a keď som pozrel v databáze, tak tam nič nebolo a pritom on ich videl v aplikácii v tabuľke.

Až keď zavrel aplikáciu, tak všetko naskákalo do tabuliek.

Dúfam, že ten autocommit bolo jediné čo to spôsobovalo.

to by mohlo být.

Taková klasika. Aplikace se používá dekády, a pak jednou jeden uživatel má nestandardní nastavení ;-)

 

Tuto diskuzi najdete na adrese https://groups.google.com/d/msgid/postgresql-cz/CAEE__4y6dvVQHeVCyYJ09nb-%2BMQH-fYOC96%3DUvRy0gqR91v2FA%40mail.gmail.com.

[Michal Bartak]

No… nejenže to zůstalo viset, ale pokud měnil data (a pravděpodobně je měnil, jinak by nedošlo k zamknutí tabulek), tak se to v databázi nikdy nezmaterializovalo.

Doporučuji nastavit idle_in_transaction_session_timeout. Výchozí hodnota je nekonečno, což z více důvodů není moc zdravé.

Podle use case by mělo stačit několik minut, maximálně desítky minut, pokud chceš být safe.

Michal

st 13. 5. 2026 v 15:11 odesílatel Emil J. <eak...@gmail.com> napsal:

Tuto diskuzi najdete na adrese https://groups.google.com/d/msgid/postgresql-cz/CAEE__4y6dvVQHeVCyYJ09nb-%2BMQH-fYOC96%3DUvRy0gqR91v2FA%40mail.gmail.com.

[Josef Šimánek]

st 13. 5. 2026 v 13:02 odesílatel Emil J. <eak...@gmail.com> napsal:

>
> Lock Monitoring zobrazil tabulku bez záznamov (ešte v čase keď UPDATE nefungovalo).
>
> Ten záznam sa momentálne tvári ako opravený. Podarilo sa mi spraviť na ňom UPDATE, aj REINDEX tabuľky.
> Neviem ako k tej "samooprave" došlo, lebo s tým bojujem už niekoľko hodín a nič mi doposiaľ nefungovalo.
> Je možné, že ten záznam/tabuľku "držal" nejaký klient ?
>
> Spravil som pg_cancel_backend() na všetky pid-y, ktoré boli spojené so zamknutím tej tabuľky, tak nerozumiem tomu.

To že pg_cancel_backend() vrátí zpět výsledek, neznamená ještě že
proces byl opravdu ukončen. Někdy nepomůže ani pg_terminate_backend().

> Tuto diskuzi najdete na adrese https://groups.google.com/d/msgid/postgresql-cz/CAEE__4yXGiAuYwkWcY5Zo5OrfZ-7bfz-ETnHGWHCYbUX7WRzpA%40mail.gmail.com.

[David Turoň]

Jeste jsem zapomel doplnit, ze je dobre mit zapnuto log_lock_waits, ktere nanestesti neni jako default on, pak vidis v logu i historicky kdo neco blokoval na dele nez deadlock_timeout.

https://www.postgresql.org/docs/17/runtime-config-logging.html#GUC-LOG-LOCK-WAITS

nastesti bude v 19 uz on (velke dik Laurenzi) a my to tak mame nastaveno leta ...

https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=2aac62be8

lze pak analyzovat log pgbadgerem a ve vystupu pak je zalozka se zamky ... nebo prohledat v logu "still waiting" - a tam je uvedeno proces holding lock - a to je to co hledas ... Je to vyhodne kdyz to visi dele, ale v momente kdy analyzujes uz se to ukoncilo ...

David

st 13. 5. 2026 v 14:34 odesílatel David Turoň <turon...@gmail.com> napsal:

[Emil J.]

Ďakujem veľmi pekne za pomoc a všetky rady a návrhy, ktoré tu zazneli.

Skúsim to podľa návrhov ponastavovať.

Tuto diskuzi najdete na adrese https://groups.google.com/d/msgid/postgresql-cz/CAFn00_wdcidoTzNwn_Bv_o65%3D%3D7PJ3ASN1tE%3D44iB%3D%2BqhN1gxA%40mail.gmail.com.