From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
Cc: | Guillaume Lelarge <guillaume(at)lelarge(dot)info>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, PostgreSQL Bugs List <pgsql-bugs(at)postgresql(dot)org> |
Subject: | Re: Confusing error message with too-large file in pg_basebackup |
Date: | 2015-11-20 20:00:55 |
Message-ID: | 26589.1448049655@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> writes:
> Guillaume Lelarge wrote:
>> Le 20 nov. 2015 1:34 PM, "Alvaro Herrera" <alvherre(at)2ndquadrant(dot)com> a
>> crit :
>>> Hmm, so we let configure --with-segsize to change the file size. The
>>> configure help says that the limit should be "less than your OS' limit
>>> on file size". We don't warn them that this could cause backup
>>> problems later on. Should we add a blurb about that somewhere?
>> If we do, we should already have done so because of the file size limit in
>> the tar format backup done with pg_dump.
> Agreed, please do. I cannot lend you my time machine right now, though,
> because I'm using it to go to a past conference I missed, so please ask
> someone else.
Um ... the segment size has no effect on pg_dump. It is true that you
can't use pg_dump's -Ft format if the text form of a table's data exceeds
8GB or whatever it is, but it matters not whether the table is segmented
internally. I'm not sure if this limitation is well-documented either,
but it's a completely different issue so far as users are concerned.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2015-11-20 20:20:12 | Re: Confusing error message with too-large file in pg_basebackup |
Previous Message | Alvaro Herrera | 2015-11-20 18:40:06 | Re: Confusing error message with too-large file in pg_basebackup |