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

From Peter Eisentraut
Subject Re: [HACKERS] Fix for large file support (nonsegment mode support)
Date
Msg-id 200803190938.15589.peter_e@gmx.net
Whole thread Raw
In response to Re: [HACKERS] Fix for large file support (nonsegment mode support)  (Zdenek Kotala <Zdenek.Kotala@Sun.COM>)
Responses Re: [HACKERS] Fix for large file support (nonsegment mode support)  (Martijn van Oosterhout <kleptog@svana.org>)
Re: [HACKERS] Fix for large file support (nonsegment mode support)  (Zdeněk Kotala <Zdenek.Kotala@Sun.COM>)
List pgsql-patches
Zdenek Kotala wrote:
> But how it was mentioned in this thread maybe
> somethink like this "CREATE TABLESPACE name LOCATION '/my/location'
> SEGMENTS 10GB" should good solution. If segments is not mentioned then
> default value is used.

I think you would need a tool to resegmentize a table or tablespace offline,
usable for example when recovering a backup.

Also, tablespace configuration information is of course also stored in a
table.  pg_tablespace probably won't become large, but it would probably
still need to be special-cased, along with other system catalogs perhaps.

An then, how to coordindate offline resegmenting and online tablespace
operations in a crash-safe way?

Another factor I just thought of is that tar, commonly used as part of a
backup procedure, can on some systems only handle files up to 8 GB in size.
There are supposed to be newer formats that can avoid that restriction, but
it's not clear how widely available these are and what the incantation is to
get at them.  Of course we don't use tar directly, but if we ever make large
segments the default, we ought to provide some clear advice for the user on
how to make their backups.

pgsql-patches by date:

Previous
From: Tatsuo Ishii
Date:
Subject: Re: Patch for testing query modes on pgbench
Next
From: Martijn van Oosterhout
Date:
Subject: Re: [HACKERS] Fix for large file support (nonsegment mode support)