Re: postgres on a non-journaling filesystem - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: postgres on a non-journaling filesystem
Date
Msg-id afaaa589-4c85-aa0a-4809-edcdb4ebfc3c@iki.fi
Whole thread Raw
In response to postgres on a non-journaling filesystem  (maayan mordehai <maayanmordehai3@gmail.com>)
Responses Re: postgres on a non-journaling filesystem  (maayan mordehai <maayanmordehai3@gmail.com>)
Re: postgres on a non-journaling filesystem  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
On 23/01/2019 01:03, maayan mordehai wrote:
> hello,
> 
> I'm Maayan, I'm in a DBA team that uses postgresql.
> I saw in the documentation on wals:
> https://www.postgresql.org/docs/10/wal-intro.html
> In the tip box that, it's better not to use a  journaling filesystem. and I
> wanted to ask how it works?
> can't we get corruption that we can't recover from?
> I mean what if postgres in the middle of a write to a wal and there is a
> crash, and it didn't finish.
> I'm assuming it will detect it when we will start postgres and write that
> it was rolled back, am I right?

Yep, any half-written transactions will be rolled back.

> and how does it work in the data level? if some of the 8k block is written
> but not all of it, and then there is a crash, how postgres deals with it?

The first time a block is modified after a checkpoint, a copy of the 
block is written to the WAL. At crash recovery, the block is restored 
from the WAL. This mechanism is called "full page writes".

The WAL works just like the journal in a journaling filesystem. That's 
why it's not necessary to have journaling at the filesystem level.

- Heikki


pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: WIP: Avoid creation of the free space map for small tables
Next
From: Nikita Glukhov
Date:
Subject: Re: jsonpath