ls -1Itt lakik a HUP PartnerünkHUP tweetjeiNépszerű témákNépszerű fórum témákÚj felhasználók
|
"Mert sokkal egyszerűbb csak kiírni egy fájlba, mint bonyolult adatbáziskezelőket behúzni függőségként"Tanulság: fájlokat jól kezelni még mindig nem egyszerű feladat, sok minden romolhat el sok rétegben. Aki úgy gondolja, hogy fájlokban adatot tárolni egyszerű, az szerintem vagy hazudik magának vagy nincs ismeretében annak, hogy mi történik a felszín alatt. És akkor még nem beszéltünk mindig arról, hogy mi van akkor, ha összefüggő adatok több fájlban vannak szétszórva.
»
|
KeresésNavigációBelépésÁllásajánlatokHWSWFriss blogbejegyzések
HUP napi hírlevélInformációKövess minket! |
Attól függ, ha csak egy fájl végére kell az új adatokat hozzácsapni és nincs többszálúság és több felhasználó, akkor felesleges egy adatbázis. Minden egyéb esetben, ha már előfordulhat konkurens hozzáférés és a régebbi adatok módosítása, akkor már érdemes adatbázis rendszerrel megtoldani a projektet.
Feltéve hogy az sem fontos hogy amit kiírtál az ki legyen írva.
Aha, nem.
* Excerpted from the LWN.net article https://lwn.net/Articles/752063/
* In short, PostgreSQL assumes that a successful call to fsync() indicates
* that all data written since the last successful call made it safely to
* persistent storage. But that is not what the kernel actually does. When
* a buffered I/O write fails due to a hardware-level error, filesystems
* will respond differently, but that behavior usually includes discarding
* the data in the affected pages and marking them as being clean. So a read
* of the blocks that were just written will likely return something other
* than the data that was written.
Magyarul: a program azt hiszi, hogy sikeres volt az írás, holott lehet, hogy valójában nem. És még azt sem feltétlen tudod, hogy temporális vagy permanens hiba történt.
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
Itt nem errol van szo. A fenti eset is az (meg a levlistan is azt irta a manus), hogy
*masodik* fsync() hivasnal volt dataloss, amikor az elso hibakodjat (EIO) nem kezelte le a pg.
Es ezt a POSIX se definialja, hogy mi ujsag, ha az fsync hibaval lep ki. Azaz ujra lehet-e probalni ugyanazt az irasi muveletet, ha az elozo fsync hibaval lepett ki.
De mielott megint savaznad a nepet. Lam, a postgresql-nek 2018-03-28-ig teljesen rendben volt ez a bug, tobb millio telepitessel, es a vilag is forgott 2018 marciusaig.
Es aki postgresql-t hasznalt 2018-ban sajat megoldas helyett akkor az hulye volt?
Egyebkent erdekes edge-case. De ennyi.
Es a man is megemliti (EIO):)
http://man7.org/linux/man-pages/man2/fdatasync.2.html
Na ez az igazi gyongyszem:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=088737f44bbf6378745f5b57b035e57ee3dc4750
---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....
Nagy szavak ezek e PG reszerol. Olyan bagoly mondja verebnek... feeling.
whoa
?
?
1997-ben írtam egy webshopot file IO alapon. Régi szép idők! Örülök, hogy elmúlt! :P
PHP-ban:)
Fokozd meg:)
---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....
Pontosan.
Amikor még a HTML tag-eket is mindenki nagybetűvel írta? :-)
:D
MS FrontPage :)