Re: [PATCHES] Fix for large file support (nonsegment mode support) - Mailing list pgsql-hackers

From Zdenek Kotala
Subject Re: [PATCHES] Fix for large file support (nonsegment mode support)
Date
Msg-id 47D6B623.1040202@sun.com
Whole thread Raw
In response to Re: [PATCHES] Fix for large file support (nonsegment mode support)  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [PATCHES] Fix for large file support (nonsegment mode support)  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: [PATCHES] Fix for large file support (nonsegment mode support)  (Peter Eisentraut <peter_e@gmx.net>)
List pgsql-hackers
Tom Lane napsal(a):
> Zdenek Kotala <Zdenek.Kotala@Sun.COM> writes:
>> Tom Lane napsal(a):
>>> These examples suggest that maybe what we want is not so much a "no
>>> segments ever" mode as a segment size larger than 1GB.
>
>> PS: ZFS is happy with 2^64bit size and UFS has 1TB file size limit
>> (depends on solaris version)
>
> So even on Solaris, "no segments ever" is actually a pretty awful idea.
> As it stands, the code would fail on tables > 1TB.
>
> I'm thinking we need to reconsider this patch.  Rather than disabling
> segmentation altogether, we should see it as allowing use of segments
> larger than 1GB.  I suggest that we ought to just flat rip out the "non
> segmenting" code paths in md.c, and instead look into what segment sizes
> are appropriate on different platforms.

Yes, agree. It seems only ZFS is OK at this moment and if somebody sets
32TB he gets nonsegment mode anyway. I looked into posix standard and
there is useful function which can be used. See

http://www.opengroup.org/onlinepubs/009695399/functions/pathconf.html

Maybe we can put additional test into configure and collect appropriate
data from buildfarm.

I think current patch could stay in CVS and I will rip out non segment
code path in a new patch.

        Zdenek

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [NOVICE] encoding problems
Next
From: Bruce Momjian
Date:
Subject: Re: Autovacuum vs statement_timeout