public inbox for [email protected]  

help / color / mirror / Atom feed

From: David Johnston <[email protected]>
To: [email protected]
Subject: Re: PATCH: Warn users about tablespace abuse data loss risk
Date: Tue, 11 Feb 2014 21:06:33 -0800 (PST)
Message-ID: <[email protected]> (raw)
In-Reply-To: <CAB8KJ=hR+tmQAxdV8Gv3tJUN3cUp5o_x4t-mj5Ub=ZhZbYBcig@mail.gmail.com>
References: <[email protected]>
	<CAB8KJ=hR+tmQAxdV8Gv3tJUN3cUp5o_x4t-mj5Ub=ZhZbYBcig@mail.gmail.com>
List-Unsubscribe: <mailto:[email protected]?body=unsub%20pgsql-docs>

Ian Lawrence Barwick wrote
> 2014-02-12 12:52 GMT+09:00 Craig Ringer &lt;

> craig@

> &gt;:
>> Hi all
>>
>> I've just seen another case of data loss due to misuse of /
>> misunderstanding of tablespaces:
>>
>> http://dba.stackexchange.com/questions/58704/how-do-i-access-a-old-saved-tablespace-after-reinstalli...
>>
>> and it's prompted me to write some docs amendments to make it more
>> obvious that *you shouldn't do that*.
>>
>> Not that it'll stop people, but it'll at least mean they can't say we
>> didn't warn them.
>>
>> This is actually quite important, because many users are used to MySQL's
>> MyISAM, where each table contains its own metadata and is readable by
>> simply copying the table into a different MySQL install's data
>> directory. It doesn't even have to be the same version! Users are
>> clearly surprised that PostgreSQL tablespaces don't have the same
>> properties.
>>
>> Thoughts?
> 
> People still use MyISAM!?
> 
> I had a similar issue pop up at work a while back, having something
> explicit to point to is definitely a good idea.
> 
> Suggestion for the first paragraph of the patch (sorry I can't provide it
> in
> patch form right now):
> 
>   Even if they are located outside the main PostgreSQL data directory,
> tablespaces
>   are an integral part of the database cluster and
> <emphasis>
> cannot
> </emphasis>
>  be
>   treated as an autonomous collection of data files. They rely on
> metadata contained
>   in the main data directory, without which they are useless. In
> particular, tablespaces
>   cannot be reattached to a different database cluster, and backing up
> individual
>   tablespaces makes no sense as a backup/redundancy method. Similarly,
> if you lose a
>   tablespace (file deletion, disk failure, etc) the main database may
> become unreadable
>   or fail to start.
> 
> Regards
> 
> 
> Ian Barwick

While providing additional warnings is good and necessary it may also help
to be more descriptive as to in what situations tablespaces are appropriate
and/or necessary so that people leave with a better understanding of why the
feature exists and not just trying to know what not to use it for.  It goes
against the more prescriptive tone of the documentation generally but both
approaches work well together to tackle the knowledge/understanding gap some
users seem to have.

David J.




--
View this message in context: http://postgresql.1045698.n5.nabble.com/PATCH-Warn-users-about-tablespace-abuse-data-loss-risk-tp579...
Sent from the PostgreSQL - docs mailing list archive at Nabble.com.


-- 
Sent via pgsql-docs mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs

view thread (7+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected]
  Subject: Re: PATCH: Warn users about tablespace abuse data loss risk
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox