Re: pg_rawdump

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: pg_rawdump
Дата
Msg-id AANLkTikTUikHY_e7zL9Pi4dYwTYfFXFk8E6L52zozH7H@mail.gmail.com
обсуждение исходный текст
Ответ на Re: pg_rawdump  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Список pgsql-hackers
On Thu, Oct 21, 2010 at 5:21 PM, Kevin Grittner
<Kevin.Grittner@wicourts.gov> wrote:
> Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
>> Most of the data-loss reports I've seen appeared to come from
>> people who wouldn't be capable of doing such recovery work even if
>> better tools were available.
>
> No doubt; but the recovery work often winds up in the hands of
> people with more skills than those responsible for the loss.
> Whoever comes in to help with recovery is looking for every bit of
> traction they can get.  You'd be amazed at some of the odd straws
> people can grasp to help recover data.
>
> I don't know how big the special area is, but if enough room could
> be carved out to include even the relation ID or filename, it might
> be a big help to someone.  I'm pretty skeptical about including
> information about attributes, though.

Unfortunately, the use case for the relation ID or filename is much
thinner than the case for the column definitions.  You're less likely
to lose that information, and if you do lose it you can probably guess
by file size or by running strings on the data files.  The really hard
thing is to remember just exactly what columns you had in there, in
what order... and oh yeah there was that column we dropped.  But like
you, I'm pretty dubious about trying to store all that stuff.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Mark Kirkwood
Дата:
Сообщение: Re: Simplifying replication
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: crash in plancache with subtransactions