Re: Wrong docs on wal_buffers?

From: "Pierre C" <lists(at)peufeu(dot)com>
To: "Josh Berkus" <josh(at)agliodbs(dot)com>, "Jeff Janes" <jeff(dot)janes(at)gmail(dot)com>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: Wrong docs on wal_buffers?
Date: 2011-01-05 22:58:32
Message-ID: op.voux3uooeorkce@apollo13
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance


> And the risks are rather asymmetric. I don't know of any problem from
> too large a buffer until it starts crowding out shared_buffers, while
> under-sizing leads to the rather drastic performance consequences of
> AdvanceXLInsertBuffer having to wait on the WALWriteLock while holding
> the WALInsertLock,

Suppose you have a large update which generates lots of WAL, some WAL
segment switching will take place, and therefore some fsync()s. If
wal_buffers is small enough that it fills up during the time it takes to
fsync() the previous WAL segment, isn't there a risk that all WAL writes
are stopped, waiting for the end of this fsync() ?

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Kevin Grittner 2011-01-05 23:10:36 Re: plan question - query with order by and limit not choosing index depends on size of limit, table
Previous Message Mike Broers 2011-01-05 22:57:07 plan question - query with order by and limit not choosing index depends on size of limit, table