Re: remove flatfiles.c - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: remove flatfiles.c
Date
Msg-id 1251824827.2889.149.camel@ebony.2ndQuadrant
Whole thread Raw
In response to Re: remove flatfiles.c  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: remove flatfiles.c
List pgsql-hackers
On Tue, 2009-09-01 at 09:58 -0400, Tom Lane wrote:

> We get beat up on a regular basis about "spikes" in response time;
> why would you want to have vacuum creating one when it doesn't need
> to?

If one I/O on a background utility can cause such a spike, we are in
serious shitake. I would be more comfortable if the various important
things VACUUM does were protected by sync commit. I see no reason to
optimise away one I/O just because we might theoretically do so. Any
mistake in the theory and we are exposed. Why take the risk? We do many
things to check and secure our data, why not this one? If this was
suggested separately it as an optimisation you'd laugh and say why
bother?

-- Simon Riggs           www.2ndQuadrant.com



pgsql-hackers by date:

Previous
From: "Kevin Grittner"
Date:
Subject: Re: Linux LSB init script
Next
From: Josh Berkus
Date:
Subject: Re: \d+ for long view definitions?