Re: shared_buffers, wal_buffers, WAL files, data files

From: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
To: Guillaume Lelarge <guillaume(at)lelarge(dot)info>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: shared_buffers, wal_buffers, WAL files, data files
Date: 2007-12-06 19:29:21
Message-ID: 20071206192921.GK8451@alvh.no-ip.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Guillaume Lelarge wrote:
> Tom Lane a écrit :
> > Guillaume Lelarge <guillaume(at)lelarge(dot)info> writes:
> >> I try to answer a simple question : what happens when I do a simple
> >> "INSERT" on a just started PostgreSQL server.
> >
> >> From what I understand with the INSERT statement, here is what happens :
> >> * backend loads first (and only) block from footable file into a shared
> >> buffer
> >> * it modifies this block on the shared buffer, and sets it as dirty
> >
> > Right, and it also makes a WAL log entry about this action.
> >
>
> The WAL log entry is made on the wal buffers (in memory). As soon as
> this statement is commited (in my example, it's right now, but in a
> BEGIN ... COMMIT statement, at COMMIT time), the wal buffer is flushed
> on WAL files. It can be flushed before if wal buffer is not big enough
> to contain all the current transactions. Am I right ?

That's correct. WAL buffers are obviously shared; when one transaction
commits it will flush not only its own entries, but also those that any
other transaction could have written.

--
Alvaro Herrera http://www.amazon.com/gp/registry/DXLWNGRJD34J
"Endurecerse, pero jamás perder la ternura" (E. Guevara)

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2007-12-06 19:34:42 Re: Better default_statistics_target
Previous Message Guillaume Lelarge 2007-12-06 18:43:59 Re: shared_buffers, wal_buffers, WAL files, data files