From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Greg Smith <gsmith(at)gregsmith(dot)com> |
Cc: | James Mansion <james(at)mansionfamily(dot)plus(dot)com>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: POSIX file updates |
Date: | 2008-04-01 05:07:17 |
Message-ID: | 20606.1207026437@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Greg Smith <gsmith(at)gregsmith(dot)com> writes:
> Quoting from Lewine's "POSIX Programmer's Guide":
> "After a write() to a regular file has successfully returned, any
> successful read() from each byte position in the file that was modified by
> that write() will return the data that was written by the write()...a
> similar requirement applies to multiple write operations to the same file
> position"
Yeah, I imagine this is what the OP is thinking of. But note that what
it describes is the behavior of concurrent write() and read() calls
within a normally-functioning system. I see nothing there that
constrains the order in which writes hit physical disk, nor (to put it
another way) that promises anything much about the state of the
filesystem after a crash.
As you stated, PG is largely independent of these issues anyway. As
long as the filesystem honors its spec-required contract that it won't
claim fsync() is complete before all the referenced data is safely on
persistent store, we are OK.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Cédric Villemain | 2008-04-01 07:53:36 | Re: Bad prepare performance |
Previous Message | Tom Lane | 2008-04-01 04:29:35 | Re: Performance Implications of Using Exceptions |