Date: Fri, 3 Sep 2021 17:22:09 -0400
From: Alvaro Herrera <alvherre@2ndquadrant.com>
To: Henry Francisco Garcia Cortez <garcortez@gmail.com>
Cc: pgsql-admin@postgresql.org, Laurenz Albe <laurenz.albe@cybertec.at>
Subject: Re: bgwriter and checkpoints
Message-ID: <202109032122.sym3vzjum5g3@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 
 <CAJP2v3E4vNx8CBsnt7W4ACs7ujk-ZmvBTCpSjamQRRYPmRLAOw@mail.gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/202109032122.sym3vzjum5g3%40alvherre.pgsql>
Precedence: bulk

On 2021-Sep-03, Henry Francisco Garcia Cortez wrote:

> Hi community, I was reading about background writer process and
> checkpoints, but I still don't understand very well. How do they work for
> instance I understand this if a row was updated,those changes will be on
> shared buffers, then those changes will go to path on disk called pg_wall,
> then when a checkpoint will be executed and finally, those changes will go
> to data files when bgwriter process will be executed but I found a blog on
> internet they say that after each search, the BGWRITER chooses some number
> of modified pages, writes them to disk, and evicts those pages from the
> shared buffer pool.

Everything you wrote here is correct.  Row changes are logged to WAL
(which is a journal -- always written to disk), and initially remain in
shared buffers.  They can be written down from shared buffers to disk
either at a checkpoint, or by bgwriter.  If they're not written down by
those processes, and the system crashes, then when the system comes
back, WAL is read and replayed.  This restores the change that was done
before the crash.

> https://flylib.com/books/en/2.290.1/the_postgresql_bgwriter_process.html

I'm not familiar with this book.

-- 
Álvaro Herrera         PostgreSQL Developer  —  https://www.EnterpriseDB.com/