RE: [HACKERS] tables > 1 gig

> -----Original Message-----
> From: Tom Lane [mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us]
> Sent: Friday, June 18, 1999 12:54 AM
> To: Bruce Momjian
> Cc: PostgreSQL-development; Inoue(at)tpf(dot)co(dot)jp
> Subject: Re: [HACKERS] tables > 1 gig
>
>
> Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us> writes:
> >> I think what we ought to do is finish working out how to make
> mdtruncate
> >> safe for concurrent backends, and then do it. That's the right
> >> long-term answer anyway.
>
> > Problem is, no one knows how right now. I liked unlinking every
> > segment, but was told by Hiroshi that causes a problem with concurrent
> > access and vacuum because the old backends still think it is there.
>
> I haven't been paying much attention, but I imagine that what's really
> going on here is that once vacuum has collected all the still-good
> tuples at the front of the relation, it doesn't bother to go through
> the remaining blocks of the relation and mark everything dead therein?
> It just truncates the file after the last block that it put tuples into,
> right?
>
> If this procedure works correctly for vacuuming a simple one-segment
> table, then it would seem that truncation of all the later segments to
> zero length should work correctly.
>
> You could truncate to zero length *and* then unlink the files if you
> had a mind to do that, but I can see why unlink without truncate would
> not work reliably.
>

Unlinking unused segments after truncating to zero length may cause
the result such as

Existent backends write to the truncated file to extend the relation
while new backends create a new segment file to extend the relation.

Comments ?

Regards.

Hiroshi Inoue
Inoue(at)tpf(dot)co(dot)jp