* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> Stephen Frost <sfrost@snowman.net> writes:
> > * Tom Lane (tgl@sss.pgh.pa.us) wrote:
> >> It's true that as soon as we need another overflow page, that's going to
> >> get dropped beyond the 2^{N+1}-1 point, and the *apparent* size of the
> >> index will grow quite a lot. But any modern filesystem should handle
> >> that without much difficulty by treating the index as a sparse file.
>
> > Uh, last I heard we didn't allow or want sparse files in the backend
> > because then we have to handle a possible out-of-disk-space failure on
> > every write.
>
> For a hash index, this would happen during a bucket split, which would
> need to be resilient against out-of-disk-space anyway.
We wouldn't attempt to use the area of the file which is not yet
allocated except when doing a bucket split? If that's the case then
this does seem to at least be less of an issue, though I hope we put in
appropriate comments about it.
> >> There may be some work to be done in places like pg_basebackup to
> >> recognize and deal with sparse files, but it doesn't seem like a
> >> reason to panic.
>
> > Well, and every file-based backup tool out there..
>
> Weren't you the one leading the charge to deprecate use of file-based
> backup?
No, nor do I see how we would ever be able to deprecate file-based
backups. If anything, I'd like to see us improve our support for
them. I'm certainly curious where the notion that I was ever in favor
of deprecating them came from, particularly given all of the effort that
David and I have been pouring into our favorite file-based backup tool
over the past few years.
Thanks!
Stephen
