Re: Run statements before pg_dump in same transaction?

From: Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>
To: François Beausoleil <francois(at)teksol(dot)info>, Forums postgresql <pgsql-general(at)postgresql(dot)org>
Subject: Re: Run statements before pg_dump in same transaction?
Date: 2017-03-23 23:48:51
Message-ID: 8d8a3652-032a-b89d-40ca-c5f7c7ab44b6@aklaver.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On 03/23/2017 12:06 PM, François Beausoleil wrote:
> Hi all!
>
> For development purposes, we dump the production database to local. It's fine because the DB is small enough. The company's growing and we want to reduce risks. To that end, we'd like to anonymize the data before it leaves the database server.
>
> One solution we thought of would be to run statements prior to pg_dump, but within the same transaction, something like this:
>
> BEGIN;
> UPDATE users SET email = 'dev+' || id || '@example.com', password_hash = '/* hash of "password" */', ...;
> -- launch pg_dump as usual, ensuring a ROLLBACK at the end
> -- pg_dump must run with the *same* connection, obviously
>
> -- if not already done by pg_dump
> ROLLBACK;
>
> Is there a ready-made solution for this? Our DB is hosted on Heroku, and we don't have 100% flexibility in how we dump.

The only thing I could find is:

https://devcenter.heroku.com/articles/heroku-postgres-backups

Direct database-to-database copies

So copy your production server to a second server on Heroku, anonymize
the data on the second server and then dump that data.

>
> I searched for "postgresql anonymize data dump before download"[1] and variations, but I didn't see anything highly relevant.
>
> Thanks!
> François
>
> PS: Cross-posted to http://dba.stackexchange.com/q/168023/3935
>
> [1]: https://duckduckgo.com/?q=postgresql+anonymize+data+dump+before+download
>
>
>

--
Adrian Klaver
adrian(dot)klaver(at)aklaver(dot)com

In response to

Browse pgsql-general by date

  From Date Subject
Next Message John DeSoi 2017-03-24 03:01:59 Re: pg_last_xact_replay_timestamp() sometimes reports unlikely, very large delays
Previous Message Adrian Klaver 2017-03-23 23:38:38 Re: audit function and old.column