Re: [HACKERS] tables > 1 gig

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us>
Cc: PostgreSQL-development <pgsql-hackers(at)postgreSQL(dot)org>, Inoue(at)tpf(dot)co(dot)jp
Subject: Re: [HACKERS] tables > 1 gig
Date: 1999-06-17 15:53:49
Message-ID: 4361.929634829@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

regards, tom lane

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 1999-06-17 16:03:37 Re: [HACKERS] tables > 1 gig
Previous Message Bruce Momjian 1999-06-17 15:41:58 New TODO item