Re: Block at a time ...

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Greg Stark <gsstark(at)mit(dot)edu>
Cc: Pierre C <lists(at)peufeu(dot)com>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Dave Crooke <dcrooke(at)gmail(dot)com>, pgsql-performance(at)postgresql(dot)org
Subject: Re: Block at a time ...
Date: 2010-03-17 14:27:04
Message-ID: 27894.1268836024@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Greg Stark <gsstark(at)mit(dot)edu> writes:
> I think we need posix_fallocate().

The problem with posix_fallocate (other than questionable portability)
is that it doesn't appear to guarantee anything at all about what is in
the space it allocates. Worst case, we might find valid-looking
Postgres data there (eg, because a block was recycled from some recently
dropped table). If we have to write something anyway to zero the space,
what's the point?

regards, tom lane

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Tom Lane 2010-03-17 14:30:43 Re: Building multiple indexes concurrently
Previous Message Justin Pitts 2010-03-17 13:52:26 Re: Testing FusionIO