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 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-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
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2003-12-17 17:12:11 | Re: [PATCHES] Double Backslash example patch |
Previous Message | Michael Meskes | 2003-12-17 15:41:45 | Re: 7.4 include file conflict |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2003-12-17 18:34:24 | Re: Excessive rows/tuples seriously degrading query |
Previous Message | Nick Fankhauser | 2003-12-17 15:26:25 | Re: Nested loop performance |