On Thu, 19 Apr 2007, Heikki Linnakangas wrote:
In the sync phase, we sleep between each fsync until enough time/segments
have passed, assuming that the time to fsync is proportional to the file
length. I'm not sure that's a very good assumption.
I've been making scatter plots of fsync time vs
Hi,
Sorry, because of so many comments/questions, I'll write inline
Josh Berkus wrote:
Hackers,
Writing lots of additional code simply to remove a parameter that
*might* be mis-interpreted doesn't sound useful to me, especially when
bugs may leak in that way. My take is that this is simpl
Hackers,
> Writing lots of additional code simply to remove a parameter that
> *might* be mis-interpreted doesn't sound useful to me, especially when
> bugs may leak in that way. My take is that this is simple and useful
> *and* we have it now; other ways don't yet exist, nor will they in time
> f
> I don't insist the name and the default of the GUC parameter.
> I'm afraid wal_fullpage_optimization = on (default) makes
> some confusion because the default behavior becomes a bit
> different on WAL itself.
Seems my wal_fullpage_optimization is not a good name if it caused
misinterpretati
On Mon, 2007-04-23 at 14:22 +0100, Heikki Linnakangas wrote:
> 8.2 branch doesn't compile with LOCK_DEBUG enabled
Applied, thanks.
-Neil
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org
8.2 branch doesn't compile with LOCK_DEBUG enabled because of a missing
include. It was added to CVS HEAD in December..
Index: src/backend/utils/misc/guc.c
===
RCS file:
/home/hlinnaka/pgcvsrepository/pgsql/src/backend/utils/misc/g
"Hiroki Kataoka" <[EMAIL PROTECTED]> writes:
> I think there is no problem. Bloating will make pages including the
> unnecessary area which will not be accessed. Soon, those pages will be
> registered into DSM.
Except the whole point of the DSM is to let us vacuum those pages *before*
that happ
