"Scott Marlowe" <scott.marlowe@xxxxxxxxx> writes: > On Thu, Oct 30, 2008 at 4:41 PM, Tom Lane <tgl@xxxxxxxxxxxxx> wrote: >> "Scott Marlowe" <scott.marlowe@xxxxxxxxx> writes: >>> On Thu, Oct 30, 2008 at 4:01 PM, Gregory Stark <stark@xxxxxxxxxxxxxxxx> wrote: >>>> I can't really see trusting Postgres on a filesystem that felt free to >>>> compress portions of it. Would the filesystem still be able to guarantee that >>>> torn pages won't "tear" across adjacent blocks? What about torn pages that >>>> included hint bits being set? >> >>> I can't see PostgreSQL noticing it. PostgreSQL hands the OS a 512byte >>> block, the OS compresses it and it's brethren as the go to disk, >>> uncompresses as they come out, and as long as what you put in is what >>> you get back it shouldn't really matter. >> >> I think Greg's issue is exactly about what guarantees you'll have left >> after the data that comes back fails to be the data that went in. > > Sounds kinda hand wavy to me. If compressed file systems didn't give > you back what you gave them I couldn't imagine them being around for > very long. I don't know, NFS has lasted quite a while. So you tell me, I write 512 bytes of data to a compressed filesystem, how does it handle the torn page problem? Is it going to have to WAL log all data operations again? -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's 24x7 Postgres support! -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
