Re: shared_buffers, wal_buffers, WAL files, data files - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: shared_buffers, wal_buffers, WAL files, data files
Date
Msg-id 20071206192921.GK8451@alvh.no-ip.org
Whole thread Raw
In response to Re: shared_buffers, wal_buffers, WAL files, data files  (Guillaume Lelarge <guillaume@lelarge.info>)
Responses Re: shared_buffers, wal_buffers, WAL files, data files  (Guillaume Lelarge <guillaume@lelarge.info>)
List pgsql-hackers
Guillaume Lelarge wrote:
> Tom Lane a écrit :
> > Guillaume Lelarge <guillaume@lelarge.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)


pgsql-hackers by date:

Previous
From: Guillaume Lelarge
Date:
Subject: Re: shared_buffers, wal_buffers, WAL files, data files
Next
From: Andrew Dunstan
Date:
Subject: Re: [BUGS] BUG #3799: csvlog skips some logs