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

Re: pg_dump --comment?

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: pg_dump --comment?
Date: 2004-05-28 14:48:56
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackerspgsql-patches
Jon Jensen wrote:

>On Fri, 28 May 2004, Christopher Kings-Lynne wrote:
>>>I've encountered a situation where I'd like to store some information 
>>>about the database when I do a pg_dump. For instance, the timestamp of 
>>>the dump. And some other information that I pull from the database.
>>I think every dump should dump the timestamp regardless...
>That would cause me a lot of trouble. Every night I do a pg_dump on all my
>databases to a temporary file. Then I use cmp to compare that dump to last
>night's dump. If they're identical I just delete the new dump so that only
>the old one remains, with its original timestamp. That way rsync doesn't
>see any change, and doesn't waste any time comparing it when we do
>backups. It's also handy to see the last day the dump changed by looking
>at the file's timestamp.
>Granted, this is only of interest on databases that don't change at all, 
>but on a multi-user system we have a surprising number of databases that 
>don't change at all for days (alongside the ones that change all the time, 
>of course).
>However, I would like to see an option to include the timestamp if someone 
>wants it.

That makes sense.

A better answer to this particular problem might be incremental dumps, 
though :-)



In response to


pgsql-hackers by date

Next:From: Andrew DunstanDate: 2004-05-28 14:57:48
Subject: Re: Win32, PITR, nested transactions, tablespaces
Previous:From: Tom LaneDate: 2004-05-28 14:38:20
Subject: Re: On query rewrite

pgsql-patches by date

Next:From: James RobinsonDate: 2004-05-28 15:15:28
Subject: Re: pg_dump --comment?
Previous:From: Jon JensenDate: 2004-05-28 14:15:38
Subject: Re: pg_dump --comment?

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