* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost <sfr...@snowman.net> writes:
> > * Tom Lane (t...@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
signature.asc
Description: Digital signature
