Skip site navigation (1) Skip section navigation (2)

Re: [HACKERS] fsync method checking

From: "Zeugswetter Andreas SB SD" <ZeugswetterA(at)spardat(dot)at>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>,"Manfred Spraul" <manfred(at)colorfullife(dot)com>
Cc: "Bruce Momjian" <pgman(at)candle(dot)pha(dot)pa(dot)us>,"Mark Kirkwood" <markir(at)paradise(dot)net(dot)nz>,<pgsql-performance(at)postgresql(dot)org>,"PostgreSQL-development" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [HACKERS] fsync method checking
Date: 2003-12-17 16:57:52
Message-ID: 46C15C39FEB2C44BA555E356FBCD6FA496208C@m0114.s-mxs.net (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-performance
> Ideally that path isn't taken very often.  But I'm currently having a
> discussion off-list with a CMU student who seems to be seeing a case
> where it happens a lot.  (She reports that both WALWriteLock and
> WALInsertLock are causes of a lot of process blockages, which seems to
> mean that a lot of the WAL I/O is being done with both held, which would
> have to mean that AdvanceXLInsertBuffer is doing the I/O.  
> More when we figure out what's going on exactly...)

I would figure, that this is in a situation where a large transaction
fills one XLInsertBuffer, and a lot of WAL buffers are not yet written.

Andreas

pgsql-performance by date

Next:From: Tom LaneDate: 2003-12-17 18:34:24
Subject: Re: Excessive rows/tuples seriously degrading query
Previous:From: Nick FankhauserDate: 2003-12-17 15:26:25
Subject: Re: Nested loop performance

pgsql-hackers by date

Next:From: Andrew DunstanDate: 2003-12-17 17:12:11
Subject: Re: [PATCHES] Double Backslash example patch
Previous:From: Michael MeskesDate: 2003-12-17 15:41:45
Subject: Re: 7.4 include file conflict

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group