Skip site navigation (1) Skip section navigation (2)

AW: Big 7.1 open items

From: Zeugswetter Andreas SB <ZeugswetterA(at)wien(dot)spardat(dot)at>
To: "'Don Baccus'" <dhogaza(at)pacifier(dot)com>, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Jan Wieck <JanWieck(at)yahoo(dot)com>, Oliver Elphick <olly(at)lfix(dot)co(dot)uk>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: AW: Big 7.1 open items
Date: 2000-06-15 08:04:51
Message-ID: 219F68D65015D011A8E000006F8590C604AF7DE7@sdexcsrv1.f000.d0188.sd.spardat.at (view raw or flat)
Thread:
Lists: pgsql-hackers
> In reality, very few people are going to be interested in restoring
> a table in a way that breaks referential integrity and other 
> normal assumptions about what exists in the database. 

This is not true. In my DBA history it would have saved me manweeks
of work if an easy and efficient restore of one single table from backup 
would have been available in Informix and Oracle.
We allways had to restore most of the whole system to another machine only
to get back at some table info that would then be manually re-added
to the production system. 
A restore of one table to a different/new tablename would have been 
very convenient, and this is currently possible in PostgreSQL.
(create new table with same schema, then replace new table data file
with file from backup)

> The reality
> is that most people are going to engage in a little time travel
> to a past, consistent backup rather than do as you suggest.

No, this is what is done most of the time, but it is very inconvenient
to tell people that they loose all work from past days, so it is usually 
done as I noted above if possible. We once had a situation where all data 
was deleted from a table, but the problem was only noticed 3 weeks later.

> This is going to be more and more true as Postgres gains more and
> more acceptance in (no offense intended) the real world.
> 
> >Right now, we use 'ps' with args to display backend 
> information, and ls
> >-l to show disk information.  We are going to lose that here.
> 
> Dependence on "ls -l" is, IMO, a very weak argument.

In normal situations where everything works I agree, it is the
error situations where it really helps if you see what data is where.
debugging, lsof, Bruce already named them.

Andreas

pgsql-hackers by date

Next:From: Zeugswetter Andreas SBDate: 2000-06-15 08:26:12
Subject: AW: Big 7.1 open items
Previous:From: Karel ZakDate: 2000-06-15 07:35:47
Subject: Re: Big 7.1 open items

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group