Em 12/12/2017 10:14, marcelo escreveu:
Hi Sam
You are right, and here are the reason behind my question: The server
where postgres will be installed is not on 24/7. It turns on in the
morning and goes off at the end of the day. The idea is that, as part
of the shutdown process, a local backup
On Tue, Dec 12, 2017 at 07:40:46AM -0500, Adam Tauno Williams wrote:
> > The next day, that backup will be copied to the cloud.
>
> What does this mean? If it is rsync of a local dump to a remote use
> the directory dump format - disable compression - then each table which
> didn't change will '
> The next day, that backup will be copied to the cloud.
What does this mean? If it is rsync of a local dump to a remote use
the directory dump format - disable compression - then each table which
didn't change will 'copy' almost instantly.
--
Meetings Coordinator, Michigan Association of Railr
Hi Sam
You are right, and here are the reason behind my question: The server
where postgres will be installed is not on 24/7. It turns on in the
morning and goes off at the end of the day. The idea is that, as part of
the shutdown process, a local backup is made. The next day, that backup
wil
I think there's a more useful question, which is why do you want to do
this? If it is just about conditional backups, surely the cost of backup
storage is low enough, even in S3 or the like, that a duplicate backup is
an afterthought from a cost perspective? Before you start jumping through
hoops
Am 11.12.2017 um 18:26 schrieb Andreas Kretschmer:
it's just a rough idea...
... and not perfect, because you can't capture ddl in this way.
Regards, Andreas
--
2ndQuadrant - The PostgreSQL Support Company.
www.2ndQuadrant.com
Am 11.12.2017 um 17:48 schrieb marcelo:
The installation I'm planning will manage several databases, but not
all of them will change every day.
In order to planning/scripting the pg_dump usage, I would need to know
which databases had some change activity at the end of some day.
How can it be
On 11 December 2017 at 11:48, marcelo wrote:
> The installation I'm planning will manage several databases, but not all of
> them will change every day.
> In order to planning/scripting the pg_dump usage, I would need to know which
> databases had some change activity at the end of some day.
> How
The two non elegant ways I can think of is checking the modification time on
the files representing the database and a query that checks the pk of all
tables. If they're ordered pk you could store the max of them and then compare,
otherwise the max of an updated at column would work as well.
Ji
Hi,
a) create triggers on some tables (on update, on delete ...).
let the triggers write some log, check the log or let the triggers
update one central table adding database, tablenames with "table ... in
database ... has been updated, modified'
b) enable detailed loggin and check the system
On Mon, Dec 11, 2017 at 01:48:44PM -0300, marcelo wrote:
> The installation I'm planning will manage several databases, but not all of
> them will change every day.
> In order to planning/scripting the pg_dump usage, I would need to know which
> databases had some change activity at the end of som
The installation I'm planning will manage several databases, but not all
of them will change every day.
In order to planning/scripting the pg_dump usage, I would need to know
which databases had some change activity at the end of some day.
How can it be done?
TIA
12 matches
Mail list logo
