Tom Lane writes:
> * postmaster log to stderr --- does this fail if log output
> exceeds 2G?
That would be an issue of the shell, not the postmaster.
--
Peter Eisentraut [EMAIL PROTECTED]
---(end of broadcast)---
TIP 5: Have you
Tom Lane writes:
> > The prototype for fseek() is long int; I had assumed that off_t was not
> > defined if _LARGEFILE_SOURCE was not defined.
All that _LARGEFILE_SOURCE does is make fseeko() and ftello() visible on
some systems, but on some systems they should be available by default.
> Oh, yo
On Tue, Aug 13, 2002 at 02:09:07PM -0400, Andrew Sullivan wrote:
> On Tue, Aug 13, 2002 at 06:45:59PM +0100, [EMAIL PROTECTED] wrote:
>
> > support isn't compiled, I didn't see one occuring from any application
> > having the support, but not the filesystem. (Your "not so standard
>
> Wrong. Th
On Tue, 2002-08-13 at 12:04, Tom Lane wrote:
> On a system where building with large-file support is reasonably
> standard, I agree that PG should be built that way too. Where it's
> not so standard, I agree with Andrew Sullivan's concerns ...
Agreed. This is what I originally asked for.
Gr
On Tue, 2002-08-13 at 12:45, [EMAIL PROTECTED] wrote:
> On Tue, Aug 13, 2002 at 01:04:02PM -0400, Tom Lane wrote:
> > On a system where building with large-file support is reasonably
> > standard, I agree that PG should be built that way too. Where it's
> > not so standard, I agree with Andrew Su
On Tue, Aug 13, 2002 at 06:45:59PM +0100, [EMAIL PROTECTED] wrote:
> support isn't compiled, I didn't see one occuring from any application
> having the support, but not the filesystem. (Your "not so standard
Wrong. The symptom is _exactly the same_ if the program doesn't have
the support, the
On Tue, Aug 13, 2002 at 01:04:02PM -0400, Tom Lane wrote:
> On a system where building with large-file support is reasonably
> standard, I agree that PG should be built that way too. Where it's
> not so standard, I agree with Andrew Sullivan's concerns ...
What do you mean by "standard"? That on
On Tue, Aug 13, 2002 at 01:04:02PM -0400, Tom Lane wrote:
>
> I see no really good reason to change the file-split logic. The places
> where the backend might possibly need large-file support are
> * backend-side COPY to or from a large file
I _think_ this causes a crash. At least, I _th
Oliver Elphick <[EMAIL PROTECTED]> writes:
> But large file support is not really an issue for the database itself,
> since table files are split at 1Gb. Unless that changes, the database
> is not a problem.
I see no really good reason to change the file-split logic. The places
where the backen
On Tue, 2002-08-13 at 17:11, Rod Taylor wrote:
> > I wouldn't totally discount using NFS for large databases. Believe it or
> > not, with an Oracle database and a Network Appliance for storage, NFS is
> > exactly what is used. We've found that we get better performance with a
> > (properly tune
Oliver Elphick wrote:
> On Tue, 2002-08-13 at 03:57, Greg Copeland wrote:
>>Ext2 & 3 should be okay. XFS (very sure) and JFS (reasonably sure)
>>should also be okay...IIRC. NFS and SMB are probably problematic, but I
>>can't see anyone really wanting to do this.
>
> Hmm. Whereas I can't see ma
Oliver Elphick <[EMAIL PROTECTED]> writes:
> On Tue, 2002-08-13 at 15:23, Tom Lane wrote:
>> Why not just use off_t? In both cases?
> The prototype for fseek() is long int; I had assumed that off_t was not
> defined if _LARGEFILE_SOURCE was not defined.
Oh, you're right. A quick look at HPUX s
On Tue, 2002-08-13 at 15:23, Tom Lane wrote:
> > typedef long int OFF_T;
>
> Why not just use off_t? In both cases?
The prototype for fseek() is long int; I had assumed that off_t was not
defined if _LARGEFILE_SOURCE was not defined.
--
Oliver Elphick[EM
Oliver Elphick <[EMAIL PROTECTED]> writes:
> Looking at how to deal with this, is the following going to be
> portable?:
> #define OFF_T_FORMAT %Ld
That certainly will not be. Use INT64_FORMAT from pg_config.h.
> typedef long int OFF_T;
Why not just use off_t? In both cases?
On Tue, 2002-08-13 at 14:26, Zeugswetter Andreas SB SD wrote:
>
> > Looking at how to deal with this, is the following going to be
> > portable?:
> No, look at the int8 code to see how to make it portable.
> On AIX e.g it is %lld and long long int.
OK. %lld is usable by glibc, so amend %Ld to
> Looking at how to deal with this, is the following going to be
> portable?:
>
> in pg_dump/Makefile:
> CFLAGS += -D_LARGEFILE_SOURCE -D_OFFSET_BITS=64
>
> in pg_dump.h:
> #ifdef _LARGEFILE_SOURCE
> #define FSEEK fseeko
> #define FTELL ftello
> #define
On Tue, Aug 13, 2002 at 08:02:05AM -0500, Larry Rosenman wrote:
> On Tue, 2002-08-13 at 03:42, Mark Kirkwood wrote:
> > Other operating systems where 64 bit file access can be disabled or
> > unconfigured require more care - possibly (sigh) 2 binary RPMS with a
> > distinctive 32 and 64 bit lab
On Tue, 2002-08-13 at 03:42, Mark Kirkwood wrote:
> Andrew Sullivan wrote:
>
> >On Sat, Aug 10, 2002 at 09:21:07AM -0500, Greg Copeland wrote:
> >
> >>I'm actually amazed that postgres isn't already using large file
> >>support. Especially for tools like dump.
> >>
> >
> >Except it would only c
On Mon, 2002-08-12 at 21:07, Peter Eisentraut wrote:
> This is not the only issue. You really need to check all uses of off_t
> (for example printf("%ld", off_t) will crash) and all places where off_t
> should have been used in the first place. Furthermore you might need to
> replace ftell() an
On Tue, 2002-08-13 at 03:57, Greg Copeland wrote:
> > Are there any filesystems in common use (not including windows ones) that
> > don't support >32-bit filesizes?
> >
> > Linux (ext2) I know supports by default at least to 2TB (2^32 x 512bytes),
> > probably much more. What about the BSDs? XFS?
Andrew Sullivan wrote:
>On Sat, Aug 10, 2002 at 09:21:07AM -0500, Greg Copeland wrote:
>
>>I'm actually amazed that postgres isn't already using large file
>>support. Especially for tools like dump.
>>
>
>Except it would only cause confusion if you ran such a program on a
>system that didn't it
On Mon, 2002-08-12 at 18:41, Martijn van Oosterhout wrote:
> On Mon, Aug 12, 2002 at 11:30:36AM -0400, Andrew Sullivan wrote:
> > The problem is not just a system-level one, but a filesystem-level
> > one. Enabling 64 bits by default might be dangerous, because a DBA
> > might think "oh, it suppo
On Mon, Aug 12, 2002 at 11:30:36AM -0400, Andrew Sullivan wrote:
> The problem is not just a system-level one, but a filesystem-level
> one. Enabling 64 bits by default might be dangerous, because a DBA
> might think "oh, it supports largefiles by default" and therefore not
> notice that the file
Oliver Elphick writes:
> One person said:
> However compiling with largefile support will change the size
> of off_t from 32 bits to 64 bits - if postgres uses off_t or
> anything else related to file offsets in a binary struct in one
> of the database files you will break stuff p
On Mon, 2002-08-12 at 11:48, Andrew Sullivan wrote:
> On Mon, Aug 12, 2002 at 11:17:31AM -0500, Greg Copeland wrote:
[snip]
> > > There are, in any case, _lots_ of problems with these large files.
>
> > All of those are SA issues.
>
> So is compiling the software correctly, if the distinctio
On Mon, 2002-08-12 at 11:40, Andrew Sullivan wrote:
> On Mon, Aug 12, 2002 at 11:07:51AM -0500, Greg Copeland wrote:
>
> > Many reasons. A DBA is not always the same thing as a developer (which
> > means it's doubtful he's even going to know about needed options to pass
> > -- if any).
>
> Thi
On Mon, Aug 12, 2002 at 11:17:31AM -0500, Greg Copeland wrote:
>
> And, what if he just remounted it read only. Mistakes will happen.
> That doesn't come across as being a strong argument to me. Besides,
> it's doubtful that a filesystem is going to be remounted while it's in
> use. Which mea
On Mon, Aug 12, 2002 at 11:07:51AM -0500, Greg Copeland wrote:
> Many reasons. A DBA is not always the same thing as a developer (which
> means it's doubtful he's even going to know about needed options to pass
> -- if any).
This (and the "upgrade" argument) are simply documentation issues.
I
On Mon, 2002-08-12 at 16:44, Lamar Owen wrote:
> Interesting point. Before I could deploy RPMs with largefile support by
> default, I would have to make sure it wouldn't silently break anything. So
> keep discussing the issues involved, and I'll see what comes of it. I don't
> have an direct
On Mon, 2002-08-12 at 11:04, Andrew Sullivan wrote:
> On Mon, Aug 12, 2002 at 11:44:24AM -0400, Lamar Owen wrote:
> > keep discussing the issues involved, and I'll see what comes of it. I don't
> > have an direct experience with the largefile support, and am learning as I go
> > with this.
>
>
On Mon, 2002-08-12 at 10:30, Andrew Sullivan wrote:
> On Mon, Aug 12, 2002 at 10:15:46AM -0500, Greg Copeland wrote:
>
> > If by "turn...on", you mean recompile, that's a horrible idea IMO.
>
> Ah. Well, that is what I meant. Why is it horrible? PostgreSQL
> doesn't take very long to compile
On Mon, Aug 12, 2002 at 11:44:24AM -0400, Lamar Owen wrote:
> > The problem is not just a system-level one, but a filesystem-level
> > one. Enabling 64 bits by default might be dangerous, because a DBA
> > might think "oh, it supports largefiles by default" and therefore not
> > notice that the f
On Monday 12 August 2002 11:30 am, Andrew Sullivan wrote:
> The problem is not just a system-level one, but a filesystem-level
> one. Enabling 64 bits by default might be dangerous, because a DBA
> might think "oh, it supports largefiles by default" and therefore not
> notice that the filesystem
On Mon, Aug 12, 2002 at 10:15:46AM -0500, Greg Copeland wrote:
> If by "turn...on", you mean recompile, that's a horrible idea IMO.
Ah. Well, that is what I meant. Why is it horrible? PostgreSQL
doesn't take very long to compile.
> I guess what I'm trying to say here is, it's moving the p
On Mon, 2002-08-12 at 09:39, Andrew Sullivan wrote:
> On Sat, Aug 10, 2002 at 09:21:07AM -0500, Greg Copeland wrote:
>
> > I'm actually amazed that postgres isn't already using large file
> > support. Especially for tools like dump.
>
> Except it would only cause confusion if you ran such a pr
On Sat, Aug 10, 2002 at 09:21:07AM -0500, Greg Copeland wrote:
> I'm actually amazed that postgres isn't already using large file
> support. Especially for tools like dump.
Except it would only cause confusion if you ran such a program on a
system that didn't itself have largefile support. Be
On Sat, 2002-08-10 at 00:25, Mark Kirkwood wrote:
> Ralph Graulich wrote:
>
> >Hi,
> >
> >just my two cents worth: I like having the files sized in a way I can
> >handle them easily with any UNIX tool on nearly any system. No matter
> >wether I want to cp, tar, dump, dd, cat or gzip the file: Jus
Ralph Graulich wrote:
>Hi,
>
>just my two cents worth: I like having the files sized in a way I can
>handle them easily with any UNIX tool on nearly any system. No matter
>wether I want to cp, tar, dump, dd, cat or gzip the file: Just keep it at
>a maximum size below any limits, handy for handlin
On Fri, 9 Aug 2002, Helge Bahmann wrote:
> > As far as I can make out from the libc docs, largefile support is
> > automatic if the macro _GNU_SOURCE is defined and the kernel supports
> > large files.
> >
> > Is that a correct understanding? or do I actually need to do something
> > special to
On Fri, 2002-08-09 at 06:07, Lamar Owen wrote:
> On Thursday 08 August 2002 05:36 pm, Nigel J. Andrews wrote:
> > Matt Kirkwood wrote:
>
> > > I just spent some of the morning helping a customer build Pg 7.2.1 from
> > > source in order to get Linux largefile support in pg_dump etc. They
> > > po
40 matches
Mail list logo
