Re: [PATCHES] Fix for large file support (nonsegment mode support)

From: Larry Rosenman <ler(at)lerctr(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-patches(at)postgresql(dot)org, Zdenek Kotala <Zdenek(dot)Kotala(at)sun(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [PATCHES] Fix for large file support (nonsegment mode support)
Date: 2008-03-11 13:59:58
Message-ID: 20080311085901.W66911@thebighonker.lerctr.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

On Mon, 10 Mar 2008, Tom Lane wrote:

> Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
>> Tom Lane wrote:
>>> Applied with minor corrections.
>
>> Why is this not the default when supported?
>
> Fear.
>
> Maybe eventually, but right now I think it's too risky.
>
> One point that I already found out the hard way is that sizeof(off_t) = 8
> does not guarantee the availability of largefile support; there can also
> be filesystem-level constraints, and perhaps other things we know not of
> at this point.
>
Just to note an additional filesystem that will need special action...
The VxFS filesystem has a largefiles option, per filesystem. At least that
was the case on SCO UnixWare (No, I no longer run it).

LER

>
> regards, tom lane
>
>

--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 512-248-2683 E-Mail: ler(at)lerctr(dot)org
US Mail: 430 Valona Loop, Round Rock, TX 78681-3893

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2008-03-11 14:37:53 Re: LISTEN vs. two-phase commit
Previous Message Tatsuo Ishii 2008-03-11 13:27:49 Re: strange pg_ctl's behavior

Browse pgsql-patches by date

  From Date Subject
Next Message Heikki Linnakangas 2008-03-11 14:03:08 Re: [PERFORM] Very slow (2 tuples/second) sequentialscan after bulk insert; speed returns to ~500 tuples/second aftercommit
Previous Message Heikki Linnakangas 2008-03-11 13:58:51 Re: TransactionIdIsInProgress() cache