Re: Would you add a --dry-run to pg_restore?

From: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
To: Edmundo Robles <edmundo(at)sw-argos(dot)com>
Cc: "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org>
Subject: Re: Would you add a --dry-run to pg_restore?
Date: 2017-08-02 16:37:41
Message-ID: CAKFQuwaBgNJNyF9Wz_wX3gY4K0rM4K_zMGdtcroza8mPqK7GUQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Wed, Aug 2, 2017 at 9:02 AM, Edmundo Robles <edmundo(at)sw-argos(dot)com> wrote:

> Will be great to have a dry run option, because the time to verify
> reduces a lot and will save space on disk, because just execute with no
> write to disk.
>

"Dry run", the way I understand it, can be accomplished via the "-l" (ell)
switch. It means - "tell me what is going to happen but don't actually do
it". I don't know what to call what you are describing but I don't see how
it could reasonably be made to work and give the admin confidence that a
true restoration would be valid. Maybe I'm just being unimaginative but at
minimum you'd have to write out the tables to disk so data could be loaded
into them. Then data would have to be persisted in order to validate the
constraints at the end.

If you are running out of disk space you should get larger/more disks.

Personally, I'd probably setup a dedicated "test restore" cluster with lots
of HD and put stuff like "fsync=off" into its postgresql.conf.

I could see having a "--make-tables-unlogged" option that would convert,
on-the-fly, all CREATE TABLE commands to "CREATE UNLOGGED TABLE" commands.

David J.

In response to

Browse pgsql-general by date

  From Date Subject
Next Message David G. Johnston 2017-08-02 16:40:31 Re: Do not INSERT if UPDATE fails
Previous Message Scott Marlowe 2017-08-02 16:23:27 Re: Do not INSERT if UPDATE fails