Re: Tablespaces on tertiary media - Mailing list pgsql-general

From Mark Morgan Lloyd
Subject Re: Tablespaces on tertiary media
Date
Msg-id fcdtth$4kf$1@pye-srv-01.telemetry.co.uk
Whole thread Raw
In response to Re: Tablespaces on tertiary media  (Gregory Stark <stark@enterprisedb.com>)
Responses Re: Tablespaces on tertiary media  (Gregory Stark <stark@enterprisedb.com>)
List pgsql-general
Gregory Stark wrote:

>> Where does PostgreSQL stand with storing /really/ large amounts of data
>> offline? Specifically, if a FUSE is used to move a tablespace to something like
>> a tape archiver can the planner be warned that access might take an extended
>> period?
>
> No, Postgres can't deal with this. You'll have to dump the tables with pg_dump
> or COPY or something like that and then drop them from the database. If you
> need them again you have to load them again.
>
> Actually if the tables are missing but nobody tries to access them (including
> autovacuum) then nothing will notice they're missing. But if you do try to
> access them you'll get an error. And if you leave it in this situation too
> long your database will shut down from getting too close to transaction
> wraparound.

Thanks. If the tables were in a tablespace that was stored on something that
looked like a conventional filesystem would the server code be prepared to
wait the minutes that it took the operating system and FUSE implementation to
load the tables onto disc?

The earlier work e.g. http://www.vldb.org/conf/1996/P156.PDF apparently warned
the planner about long-latency devices but that's probably unnecessary if the
application program was aware that a table had been partitioned by age and
accessing old data could be slow.

--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]

pgsql-general by date:

Previous
From: "Phoenix Kiula"
Date:
Subject: Re: Issue with uninstalling postgres 8.1.9
Next
From: Gregory Stark
Date:
Subject: Re: Tablespaces on tertiary media