Dotaz: Může v postgresql být smazán řádek z ještě nepřečtené result set?

[kalik]

Ahoj.

V php pomocí PDO si připravím SELECT dotaz, spustím ho a pak postupně procházím jednotlivé řádky pomocí foreach s tím, že v každém cyklu si fetchnu jeden řádek. Zjistil jsem, že i když po spuštění SELECT dotazu smažu některé řádky, které jsem ještě nestačil fetchnout, tak stejně se takové řádky ve výsledku objeví i když už jsou fyzicky smazané.

Jak je to možné? Nějaká cache? Mám záruku, že to tak bude pořád? Rád bych si napsal iterátor třídu pro procházení obrovského množství řádků, abych ušetřil paměť. Bude i v případě procházení milionů řádků result set "imunní" než ho stačím celý fetchnout?

Odpovědi

[Ivan]

MVCC

[kalik]

Aha, děkuji. Já jsem myslel, že toto funguje jen když čtu data ovlivněná jinou transakcí. Ovlivňuje toto chování i nastavení úrovně izolace "SET SESSION CHARACTERISTIC"?

[Ivan]

IMHO Izolacni uroven uvlivnuje to co uvidite to co "vidite" mezi jednotlivymi SELECTy. Kazdy jednotlivy dotaz by mel vracet konzistentni pohled na data, to by jinak bylo dost nedeterminsticke.

[Filip Jirsák]

Chování záleží na tom, jak máte nastavenu izolaci transakcí. Když použijete repeatable read, uvidíte v rámci jedné transakce vždy stav, který byl na začátku transakce – takže jiné transakce mohou mazat nebo insertovat, a váš result set to neovlivní.

Procházením obrovského množství řádků paměť neušetříte, právě naopak. Server si nějakým způsobem tu výslednou sadu pamatovat musí – ať už přímo jako výsledek, nebo jako zdrojová data, ze kterých ten výsledek dokáže sestavit.

[kalik]

Jako výchozí jsem nastavil SERIALIZABLE. Nicméně ten SELECT nebyl spuštěný v transakci a stejně to výsledný result set neovlivnilo. Nebo to postgresql bere tak, že každý dotaz je vlastně transakce?

[Filip Jirsák]

Nicméně ten SELECT nebyl spuštěný v transakci

Byl. V PostgreSQL (a v každém jiném rozumném systému s podporou transakcí) dotaz mimo transakci nespustíte.

Nebo to postgresql bere tak, že každý dotaz je vlastně transakce?

Transakce se zahájí automaticky. Pravděpodobně máte v PDO nastavený autocommit, takže se pak každý příkaz provádí v samostatné transakci.

[Kit]

... Pravděpodobně máte v PDO nastavený autocommit, takže se pak každý příkaz provádí v samostatné transakci.

Autocommit přece s PDO nesouvisí. Není to vlastnost databázového klienta, ale serveru.

[Filip Jirsák]

Autocommit je vždy možné konfigurovat z klienta. To, zda je implementován na serveru, nebo tak, že klient po každém příkazu pošle commit, je podle mne implementační detail. Konkrétně v případě PostgreSQL podle mne server nic takového neumí a autocommit je vždy záležitostí implementace klienta.

[Filip Jirsák]

Aha, tak ne, omlouvám se - implicitně zahájená transakce je po úspěšném provedení také commitnuta, takže pokud se nezahájí transakce explicitně BEGIN, funguje to jako autocommit.

[Marek]

Tazatel chce zrejme setrit pamet u klienta, ne u serveru.

[j]

"Zjistil jsem, že i když po spuštění SELECT dotazu smažu některé řádky, které jsem ještě nestačil fetchnout, tak stejně se takové řádky ve výsledku objeví i když už jsou fyzicky smazané."

Pomerne logicky, nemyslis? Select ti vrati data do nejakyho bufferu a ty uz pri foreach nepracujes s datama v databazi, ale s datama v tom vracenym vysledku.

SERIALIZABLE ti na to nepomuze, jakmile select dobehne, tak pokud neotevres explicitne transakci a nenechasi ji viset po celou dobu prochazeni vysledku, tak se okamzite ukonci.

Pokud nactes milion radku, a nemas na to dost RAM, tak ti to proste zbuchne. Takova prace s databazi je ovsem ponekud knicemu. Protoze ty si stavis dalsi, zcela nesmyslnou vrstvu nad tou databazi.

[Ivan]

Tenhle prece neni o najakych bufferech. PostgreSQL uklada kazdou zmenenou radku na nove misto(a ma i poiter na predchozi verzi stavu te radky). O uklid se stara VACUUM. Takze kdyz sql select nacte block s radkou, ktera ma novejsi timestamp, nez je zacatek transakce tak se proste podiva na predchozi stav te radky.

To je princip implementace MVCC, do databaze se ukladaji vsechny predchozi stavy dat, ktere jsou jeste potreba.

[Filip Jirsák]

MVCC je způsob implementace v PostgreSQL. Pro tazatele je ale důležité, že přesně tohle řeší různé úrovně izolace transakcí – a to, jak databáze tu úroveň izolace zařídí, je implementační detail. Zároveň je potřeba vědět, že izolaci transakcí sice definuje standard, ale je to dost všeobecné – a jaké skutečně dává která úroveň záruky, to se dozví jedině z dokumentace konkrétní databáze.

[kalik]

Chápu to dobře, že po begin transaction mám až do commitu pohled na data konstantní, jako byl před zahájením transakce? Tzn. začnu transakci, provedu select z jedné tabulky, pak nesouvisející select z druhé atd. a mám jistotu, že ta data jsou pořád pro mě zevnitř transakce nezměněná jako před začátkem transakce?

[Filip Jirsák]

To platí jen v případě, že máte úroveň oddělení transakcí alespoň repeatable read. Pokud použijete read committed (v PostgreSQL je výchozí) nebo read uncommited (v jiné databázi, PostgreSQL to neumí), a spustíte v jedné transakci dvakrát za sebou stejný select, může dát pokaždé jiné výsledky, pokud podkladovou tabulku mezi tím změnila jiná transakce. Když použijete repeatable read, vidíte tabulky ve stavu, v jakém byly na začátku transakce (plus samozřejmě změny provedené aktuální transakcí).

[michal00]

toto s transakciami nemá nič. result je uložený v buffery PHP, pri volaní pg_fetch_assoc to zbehne z toho resultu. aj keď sql server už nebeží, zmazala sa tabuľka, zmazali sa dáta. v tom čase sa vôbec nepýta sql server, všetko je vnútri php.

rovnako ako keď v psql zbehnem query a potom ju iba pozerám v pageri. medzitým kľudne môžem zformátovať disk s databázou a psql si nič nevšimne (feature, nie bug).

[Ivan]

A ten buffer ma nekonecnou velikost? To asi ne. Aplikace a databaze pracuji na principu producent-konzument. Tzn. v okamziku kdy se blizite k konci bufferu klient poste do databaze pozadavek dalsi davku dat. Proto je pro databazi dulezite pamatovat si timestamp okamziku kdy se zacal dotaz provadet, potom muze databaze zpracovavat pouze bloky, ktere byly modifikovane pred tim timestamp-em. Ono to jen "vypada", ze se dotaz vykonal v jeden okamzik.

[okbob]

Ono je to trochu složitější - Postgres, pokud se nepoužívají kurzory (které se běžně nepoužívají), tak okamžitě po spočítání řádků posílá data na klienta, kde se přijatá data alokují do lokální paměti. Ta skutečně není nekonečná, a pokud si vrátíte milióny řádků, tak ještě než začnete v klientovi zpracovávat data (např. v PHP), tak Vám to celé spadne na nedostatku paměti. Jakmile se dotaz spočítá (postgres se chová transakčně), tak se začíná krmit koncový klient (např. PHP), který může převzít data jednorázově a nebo po blocích (ale čte se z lokální paměti, která obsahuje kompletní výsledek). Lze to udělat i jinak, ale to není běžné a běžně se to nepoužívá. Tedy PostgreSQL bufferuje výsledek (pokud někde výpočet spadne, tak vrátí 0 řádek), a vždy bufferuje na straně klienta (což je trochu nečekané, ale je to tak). Ohledně timestampů je také trochu jinak. Postgres použivá multigenerační architekturu, kdy od jednoho záznamu mohu mít v databázi uloženo více verzí. Každá verze záznamu má v sobě číslo transakce, která tu verzi vyrobila a někde bokem je informace, jestli ta transakce už doběhla nebo nikoliv, případně jestli doběhla úspěšně nebo nikoliv. Pak podle nějakých pravidel se zjišťuje, kdo, kdy může vidět kterou verzi záznamu. Např. nemůžete vidět verze, které jsou z nepotvrzené transakce.

[Ivan]

Aha tak to se omlouvam, ze jsem mlzil(kecal) nejak jsem predpokladal, ze to funguje podobne jako u ostatnich databazi.

[okbob]

Ono tohle moc lidí neví - ale má to svou logiku - distribuuje se využití paměti na klienta, a snižuje se i riziko, že dotaz bude brzdit klient, a navíc je transakční ve smyslu "vrátí všechno nebo nic". A pokud by to výchozí způsob byl příliš náročný na paměť, tak lze použít kurzor.

[j]

Cece ...? Php (ale na tom vubec nesejde) preda SQLku dotaz. SQLko vrati VSECHNA data, ktera tomu dotazu odpovidaji. Jak stim potom nalozi programator, uz databazi lautr nezajima.

Programator si ty data muze narvat do pameti, muze si je narvat na disk ... to je jeho problem, SQLko mu proste vrati resultset, se kterym on muze nejak nakladat. Ale SQLko nemuze vubec nijak resit obsah toho vysledku, protoze uz je zcela mimo jeho kontrolu.

Je to presne stejny, jako kdyz v databazi napises kursor. Pokud ti celej pobezi v jedny transakci, tak si tim muzes zajistit, ze se mezi tim data nezmeni - a samo tim taky zaridis peknou varku deadlocku. Ale pokud tu transakci takto sam nevytvoris, tak ti select do kursoru vrati result, a pak si klidne muzes smazat celou tu databazi, ten result uz to nezmeni.

Presne proto je tohle (selectovani hromady dat) poradne blbej napad.

[Michal Kubeček]

Je to presne stejny, jako kdyz v databazi napises kursor. Pokud ti celej pobezi v jedny transakci, tak si tim muzes zajistit, ze se mezi tim data nezmeni - a samo tim taky zaridis peknou varku deadlocku.

Pokud to bude read only, není důvod, aby kvůli tomu něco deadlockovalo.

[Bill Gates]

Aniz bych procital diskuzi pod dotazem, prijde mi logicke, ze kdyz udelam select tak dostanu data v momente selectu. Jinak by se select musel pokazde znovu provest (zaktualizovat) pri kazdem zasahu do databaze znovu, aby se zjistil aktualni stav a to by behem cteni meniciho se resultu udelalo asi pekny chaos a navic by to mohlo byt docela casove hodne narocne.