On Sun, 2006-11-19 at 12:03 -0800, David Fetter wrote:
> On Sun, Nov 19, 2006 at 12:01:15PM -0800, Joshua D. Drake wrote:
> > On Sun, 2006-11-19 at 11:28 -0800, Josh Berkus wrote:
> > > Tom,
> > >
> > > > Let's go with the easy fix. With regular 1GB segment size,
> > > > having a few empty files
Heikki Linnakangas wrote:
Florian G. Pflug wrote:
Joshua D. Drake wrote:
On Sun, 2006-11-19 at 11:28 -0800, Josh Berkus wrote:
Tom,
Let's go with the easy fix. With regular 1GB segment size, having a
few
empty files in the data directory isn't going to hurt anyone.
No, but it will confuse DB
Florian G. Pflug wrote:
Joshua D. Drake wrote:
On Sun, 2006-11-19 at 11:28 -0800, Josh Berkus wrote:
Tom,
Let's go with the easy fix. With regular 1GB segment size, having a few
empty files in the data directory isn't going to hurt anyone.
No, but it will confuse DBAs ("What the heck are all t
Joshua D. Drake wrote:
On Sun, 2006-11-19 at 11:28 -0800, Josh Berkus wrote:
Tom,
Let's go with the easy fix. With regular 1GB segment size, having a few
empty files in the data directory isn't going to hurt anyone.
No, but it will confuse DBAs ("What the heck are all these 0B files?"). Maybe
On Sun, Nov 19, 2006 at 12:01:15PM -0800, Joshua D. Drake wrote:
> On Sun, 2006-11-19 at 11:28 -0800, Josh Berkus wrote:
> > Tom,
> >
> > > Let's go with the easy fix. With regular 1GB segment size,
> > > having a few empty files in the data directory isn't going to
> > > hurt anyone.
> >
> > No
On Sun, 2006-11-19 at 11:28 -0800, Josh Berkus wrote:
> Tom,
>
> > Let's go with the easy fix. With regular 1GB segment size, having a few
> > empty files in the data directory isn't going to hurt anyone.
>
> No, but it will confuse DBAs ("What the heck are all these 0B files?").
> Maybe
> we
Tom,
> Let's go with the easy fix. With regular 1GB segment size, having a few
> empty files in the data directory isn't going to hurt anyone.
No, but it will confuse DBAs ("What the heck are all these 0B files?"). Maybe
we should add code to VACUUM to look for these empty file segments and un
Tom Lane wrote:
I think that the easiest fix might be to not remove no-longer-used
segment files during a truncate, but simply reduce them to zero size
rather than delete them. Then any open file pointers aren't
invalidated. The only alternative I can see is to invent some new
signaling mechani
Tom Lane wrote:
>
> I think that the easiest fix might be to not remove no-longer-used
> segment files during a truncate, but simply reduce them to zero size
> rather than delete them. Then any open file pointers aren't
> invalidated. The only alternative I can see is to invent some new
> signal
Russell Smith <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> What is happening is that during that 30-second wait, the bgwriter is
>> dumping out all the dirty pages, and acquiring open file references
>> to each segment of table "foo" as it does so. The VACUUM then truncates
>> "foo" back to ze
Tom Lane wrote:
While working on fixing the recently reported hash-index problem,
I was using a test build with a very small RELSEG_SIZE (128K),
so that I could trigger the reported bug with a reasonably small
amount of data. And I started finding some unexpected data corruption.
I eventually re
11 matches
Mail list logo
