| From: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
|---|---|
| To: | Albe Laurenz <laurenz(dot)albe(at)wien(dot)gv(dot)at> |
| Cc: | "t(dot)dalpozzo(at)gmail(dot)com *EXTERN*" <t(dot)dalpozzo(at)gmail(dot)com>, "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org> |
| Subject: | Re: journaled FS and and WAL |
| Date: | 2016-10-15 05:52:04 |
| Message-ID: | CAB7nPqSk3q0vjK=X3wK=Fw05WFOcJByXMtiOvBPXA84HvPi-Aw@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On Fri, Oct 14, 2016 at 11:27 PM, Albe Laurenz <laurenz(dot)albe(at)wien(dot)gv(dot)at> wrote:
> After a successful commit, the WAL file and its metadata are on disk.
> Moreover, the file metadata won't change (except for the write and access
> timestamps) because WAL files are created with their full size and never
> extended, so no WAL file should ever get "lost" because of partial metadata
> writes.
This behavior depends as well on the value of wal_sync_method. For
example with fdatasync the metadata is not flushed. It does not matter
any for for WAL segments as Albe has already mentioned, but the choice
here impacts performance.
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Antonio Silva | 2016-10-15 17:11:01 | could not connect to server |
| Previous Message | Periko Support | 2016-10-14 16:20:03 | Re: [Bucardo-general] doubts about target db? |