With this commit, PsqlForks ( http://psqlforks.com ) can now fetch credentials from AWS IAM. Read more about Redshift's support for generating database credentials using IAM authentication feature, here.
Since the entire AWS CLI isn't baked into PsqlForks (yet!), you'd need a working copy of AWS CLI installed / working on the host (from where psql is called).
This took a while, since I missed the basic assumption that Redshift enforces SSL and psql doesn't attempt SSLMODE by default in the first try. The fact that CYGWIN wasn't super-smooth with AWS CLI in my test installation, didn't help either.
But as they say, all's well that ends well. There are few obvious additions that are possible (such as expiration validation / re-use unexpired credentials on re-connect etc.) but this should get merged in the forks mainline soon.
I guess it's time to begin thinking of releases, instead of making the mainline jittery with feature additions such as this one.
Yenjoy!
$ psql "sslmode=require host=redshift_cluster port=5439 dbname=redshift2" -U testing1
Password for user testing1:
psql: fe_sendauth: no password supplied
$ psql -I "sslmode=require host=redshift_cluster port=5439 dbname=redshift2" -U testing1
CLI: aws redshift get-cluster-credentials --auto-create --db-user testing1 --cluster-identifier redshift2 # Informational / testing output
psql (client-version:11devel, server-version:8.0.2, engine:redshift)
SSL connection (protocol: TLSv1.2, cipher: ECDHE-RSA-AES256-GCM-SHA384, bits: 256, compression: on)
Type "help" for help.
redshift2=> select current_user;
current_user
--------------
testing1
(1 row)
redshift2=> \du
List of roles
Role name | Attributes | Member of
-----------+-------------------------------+-----------
redshift2 | Superuser, Create DB +|
| Password valid until infinity |
testing1 | |
redshift2=> \q
$ ./psql --help | grep -i iam
-I, --aws-iam-redshift use temporary database credentials from AWS IAM Service
Showing posts with label gpl. Show all posts
Showing posts with label gpl. Show all posts
13 Oct 2017
12 Oct 2017
PsqlForks now recognizes RDS PostgreSQL separately
With this commit, PsqlForks ( http://psqlforks.com ) now recognizes RDS PostgreSQL separately.
This isn't utilized much yet, but the infrastructure is going to be helpful in skipping / avoiding some commands that are defunct / not possible in the RDS PostgreSQL offering.
This isn't utilized much yet, but the infrastructure is going to be helpful in skipping / avoiding some commands that are defunct / not possible in the RDS PostgreSQL offering.
29 Sept 2017
PsqlForks now recognizes PgBouncer
With this commit, PsqlForks knows when it's talking to PgBouncer (and not Postgres).
Down the line, this should pave way for PsqlForks to more cleanly convey why (most of) the given psql shortcut(s) don't work (and what else does).
As always, the psql/README always has the most updated status of any engine support.
$ psql -h localhost -E -p6543 -U postgres pgbouncer
psql (client-version:11devel, server-version:1.7.1/bouncer, engine:pgbouncer)
Type "help" for help.
pgbouncer=# show version;
NOTICE: pgbouncer version 1.7.1
SHOW
pgbouncer=#
Down the line, this should pave way for PsqlForks to more cleanly convey why (most of) the given psql shortcut(s) don't work (and what else does).
As always, the psql/README always has the most updated status of any engine support.
$ psql -h localhost -E -p6543 -U postgres pgbouncer
psql (client-version:11devel, server-version:1.7.1/bouncer, engine:pgbouncer)
Type "help" for help.
pgbouncer=# show version;
NOTICE: pgbouncer version 1.7.1
SHOW
pgbouncer=#
25 Sept 2017
PsqlForks now supports CockroachDB
PsqlForks now supports CockroachDB as much as is currently possible. You can check it's current SQL status here.
$ /opt/postgres/master/bin/psql -h localhost -E -p 26257 -U root
psql (client-version:11devel, server-version:9.5.0, engine:cockroachdb)
Type "help" for help.
root=> select version();
version()
--------------------------------------------------------------------------
CockroachDB CCL v1.0.6 (linux amd64, built 2017/09/14 15:15:48, go1.8.3)
(1 row)
bank=> \l
$ /opt/postgres/master/bin/psql -h localhost -E -p 26257 -U root
psql (client-version:11devel, server-version:9.5.0, engine:cockroachdb)
Type "help" for help.
root=> select version();
version()
--------------------------------------------------------------------------
CockroachDB CCL v1.0.6 (linux amd64, built 2017/09/14 15:15:48, go1.8.3)
(1 row)
bank=> \l
List of databases
Name | Owner | Encoding | Collate | Ctype | Access privileges
--------------------+-------+-------------------+------------+------------+-------------------
bank | | Not Supported Yet | en_US.utf8 | en_US.utf8 | Not Supported Yet
crdb_internal | | Not Supported Yet | en_US.utf8 | en_US.utf8 | Not Supported Yet
information_schema | | Not Supported Yet | en_US.utf8 | en_US.utf8 | Not Supported Yet
pg_catalog | | Not Supported Yet | en_US.utf8 | en_US.utf8 | Not Supported Yet
system | | Not Supported Yet | en_US.utf8 | en_US.utf8 | Not Supported Yet
(5 rows)
bank=> \dv
List of relations
Schema | Name | Type | Owner
--------+------+------+-------
bank | a | view |
(1 row)
bank=> \di
List of relations
Schema | Name | Type | Owner | Table
--------+-------------------------+-------+-------+------------
bank | primary | index | | accounts
system | jobs_status_created_idx | index | | jobs
system | primary | index | | descriptor
system | primary | index | | eventlog
system | primary | index | | jobs
system | primary | index | | lease
system | primary | index | | namespace
system | primary | index | | rangelog
system | primary | index | | settings
system | primary | index | | ui
system | primary | index | | users
system | primary | index | | zones
(12 rows)
15 Sept 2017
PsqlForks now supports PipelineDB
After working on this PSQL variant that intends to support all Postgres forks, I finally narrowed down to naming it.
Since this was essentially Psql (for) Forks, quite intuitively, I chose to name it PsqlForks.
Considering that until recently this fork just supported Amazon Redshift, this naming didn't make much sense if it wasn't supporting at least 2 forks :) !
Thus, PsqlForks now supports PipelineDB!
$ /opt/postgres/master/bin/psql -U pipeline -p 5434 -h localhost pipeline
psql (client-version:11devel, server-version:9.5.3, engine:pipelinedb)
Type "help" for help.
pipeline=# \q
Since this was essentially Psql (for) Forks, quite intuitively, I chose to name it PsqlForks.
Considering that until recently this fork just supported Amazon Redshift, this naming didn't make much sense if it wasn't supporting at least 2 forks :) !
Thus, PsqlForks now supports PipelineDB!
$ /opt/postgres/master/bin/psql -U pipeline -p 5434 -h localhost pipeline
psql (client-version:11devel, server-version:9.5.3, engine:pipelinedb)
Type "help" for help.
pipeline=# \q
2 Sept 2017
psql \d now supports Interleaved / Compound SORTKEYs (in Redshift)
In continuation of support for Redshift series, now Describe Table (for e.g. \d tbl) shows SORTKEY details. This resolves Issue #6 and shows both COMPOUND / INTERLEAVED variations along with all the column names.
This change was complicated because Redshift doesn't natively support LISTAGG() function on System / Catalog tables, which meant that I had to resort to a pretty verbose workaround. This in-turn meant that this patch shows only the first ten COMPOUND SORTKEYs of a table. Seriously speaking, it would really take an extreme corner-case, for someone to genuinely require a SORTKEY with 10+ columns.
This is not a limitation for INTERLEAVED SORTKEY since it only supports a maximum of 8 Columns.
db=# CREATE TABLE tbl_pk(custkey SMALLINT PRIMARY KEY);
CREATE TABLE
db=# \d tbl_pk
Table "public.tbl_pk"
Column | Type | Encoding | DistKey | SortKey | Preload | Encryption | Collation | Nullable | Default
---------+----------+----------+---------+---------+---------+------------+-----------+----------+---------
custkey | smallint | lzo | f | 0 | f | none | | not null |
Indexes:
PRIMARY KEY, btree (custkey)
db=# CREATE TABLE tbl_compound(
db(# custkey SMALLINT ENCODE delta NOT NULL,
db(# custname INTEGER DEFAULT 10 ENCODE raw NULL,
db(# gender BOOLEAN ENCODE RAW,
db(# address CHAR(5) ENCODE LZO,
db(# city BIGINT identity(0, 1) ENCODE DELTA,
db(# state DOUBLE PRECISION ENCODE Runlength,
db(# zipcode REAL,
db(# tempdel1 DECIMAL ENCODE Mostly16,
db(# tempdel2 BIGINT ENCODE Mostly32,
db(# tempdel3 DATE ENCODE DELTA32k,
db(# tempdel4 TIMESTAMP ENCODE Runlength,
db(# tempdel5 TIMESTAMPTZ ENCODE DELTA,
db(# tempdel6 VARCHAR(MAX) ENCODE text32k,
db(# start_date VARCHAR(10) ENCODE TEXT255
db(# )
db-# DISTSTYLE KEY
db-# DISTKEY (custname)
db-# COMPOUND SORTKEY (custkey, custname, gender, address, city, state, zipcode, tempdel1, tempdel2, tempdel3, tempdel4, tempdel5, start_date);
CREATE TABLE
db=#
db=# \d tbl_compound
Table "public.tbl_compound"
Column | Type | Encoding | DistKey | SortKey | Preload | Encryption | Collation | Nullable | Default
------------+-----------------------------+-----------+---------+---------+---------+------------+-----------+----------+------------------------------------
custkey | smallint | delta | f | 1 | f | none | | not null |
custname | integer | none | t | 2 | f | none | | | 10
gender | boolean | none | f | 3 | f | none | | |
address | character(5) | lzo | f | 4 | f | none | | |
city | bigint | delta | f | 5 | f | none | | | "identity"(494055, 4, '0,1'::text)
state | double precision | runlength | f | 6 | f | none | | |
zipcode | real | none | f | 7 | f | none | | |
tempdel1 | numeric(18,0) | mostly16 | f | 8 | f | none | | |
tempdel2 | bigint | mostly32 | f | 9 | f | none | | |
tempdel3 | date | delta32k | f | 10 | f | none | | |
tempdel4 | timestamp without time zone | runlength | f | 11 | f | none | | |
tempdel5 | timestamp with time zone | delta | f | 12 | f | none | | |
tempdel6 | character varying(65535) | text32k | f | 0 | f | none | | |
start_date | character varying(10) | text255 | f | 13 | f | none | | |
Indexes:
COMPOUND SORTKEY (address,tempdel2,start_date,custkey,zipcode,tempdel4,city,state,tempdel3,custname)
db=# CREATE TABLE tbl_interleaved(custkey SMALLINT) INTERLEAVED SORTKEY (custkey);
CREATE TABLE
db=# \d tbl_interleaved
Table "public.tbl_interleaved"
Column | Type | Encoding | DistKey | SortKey | Preload | Encryption | Collation | Nullable | Default
---------+----------+----------+---------+---------+---------+------------+-----------+----------+---------
custkey | smallint | none | f | 1 | f | none | | |
Indexes:
INTERLEAVED SORTKEY (custkey)
This change was complicated because Redshift doesn't natively support LISTAGG() function on System / Catalog tables, which meant that I had to resort to a pretty verbose workaround. This in-turn meant that this patch shows only the first ten COMPOUND SORTKEYs of a table. Seriously speaking, it would really take an extreme corner-case, for someone to genuinely require a SORTKEY with 10+ columns.
This is not a limitation for INTERLEAVED SORTKEY since it only supports a maximum of 8 Columns.
db=# CREATE TABLE tbl_pk(custkey SMALLINT PRIMARY KEY);
CREATE TABLE
db=# \d tbl_pk
Table "public.tbl_pk"
Column | Type | Encoding | DistKey | SortKey | Preload | Encryption | Collation | Nullable | Default
---------+----------+----------+---------+---------+---------+------------+-----------+----------+---------
custkey | smallint | lzo | f | 0 | f | none | | not null |
Indexes:
PRIMARY KEY, btree (custkey)
db=# CREATE TABLE tbl_compound(
db(# custkey SMALLINT ENCODE delta NOT NULL,
db(# custname INTEGER DEFAULT 10 ENCODE raw NULL,
db(# gender BOOLEAN ENCODE RAW,
db(# address CHAR(5) ENCODE LZO,
db(# city BIGINT identity(0, 1) ENCODE DELTA,
db(# state DOUBLE PRECISION ENCODE Runlength,
db(# zipcode REAL,
db(# tempdel1 DECIMAL ENCODE Mostly16,
db(# tempdel2 BIGINT ENCODE Mostly32,
db(# tempdel3 DATE ENCODE DELTA32k,
db(# tempdel4 TIMESTAMP ENCODE Runlength,
db(# tempdel5 TIMESTAMPTZ ENCODE DELTA,
db(# tempdel6 VARCHAR(MAX) ENCODE text32k,
db(# start_date VARCHAR(10) ENCODE TEXT255
db(# )
db-# DISTSTYLE KEY
db-# DISTKEY (custname)
db-# COMPOUND SORTKEY (custkey, custname, gender, address, city, state, zipcode, tempdel1, tempdel2, tempdel3, tempdel4, tempdel5, start_date);
CREATE TABLE
db=#
db=# \d tbl_compound
Table "public.tbl_compound"
Column | Type | Encoding | DistKey | SortKey | Preload | Encryption | Collation | Nullable | Default
------------+-----------------------------+-----------+---------+---------+---------+------------+-----------+----------+------------------------------------
custkey | smallint | delta | f | 1 | f | none | | not null |
custname | integer | none | t | 2 | f | none | | | 10
gender | boolean | none | f | 3 | f | none | | |
address | character(5) | lzo | f | 4 | f | none | | |
city | bigint | delta | f | 5 | f | none | | | "identity"(494055, 4, '0,1'::text)
state | double precision | runlength | f | 6 | f | none | | |
zipcode | real | none | f | 7 | f | none | | |
tempdel1 | numeric(18,0) | mostly16 | f | 8 | f | none | | |
tempdel2 | bigint | mostly32 | f | 9 | f | none | | |
tempdel3 | date | delta32k | f | 10 | f | none | | |
tempdel4 | timestamp without time zone | runlength | f | 11 | f | none | | |
tempdel5 | timestamp with time zone | delta | f | 12 | f | none | | |
tempdel6 | character varying(65535) | text32k | f | 0 | f | none | | |
start_date | character varying(10) | text255 | f | 13 | f | none | | |
Indexes:
COMPOUND SORTKEY (address,tempdel2,start_date,custkey,zipcode,tempdel4,city,state,tempdel3,custname)
db=# CREATE TABLE tbl_interleaved(custkey SMALLINT) INTERLEAVED SORTKEY (custkey);
CREATE TABLE
db=# \d tbl_interleaved
Table "public.tbl_interleaved"
Column | Type | Encoding | DistKey | SortKey | Preload | Encryption | Collation | Nullable | Default
---------+----------+----------+---------+---------+---------+------------+-----------+----------+---------
custkey | smallint | none | f | 1 | f | none | | |
Indexes:
INTERLEAVED SORTKEY (custkey)
As a side-note, there is a consideration as to whether this should be on a separate section of its own (and not under Indexes, which it clearly isn't). May be another day. Happy Redshifting :) !
Update (15th Sep 2017):
This project has now been named PsqlForks!
Update (15th Sep 2017):
This project has now been named PsqlForks!
31 Aug 2017
psql \d now supports DISTKEY / SORTKEY / ENCODING (in Redshift)
This is in continuation of my work for (my forked version of) psql to better support Redshift (read more here).
Now \d table provides some additional Redshift specific table properties such as:
Now \d table provides some additional Redshift specific table properties such as:
- DISTKEY
- SORTKEY
- COMPRESSION (ENCODING)
- ENCRYPTION
Sample:
t3=# CREATE TABLE customer(
custkey SMALLINT ENCODE delta NOT NULL,
custname INTEGER DEFAULT 10 ENCODE raw NULL,
gender BOOLEAN ENCODE RAW,
address CHAR(5) ENCODE LZO,
city BIGINT identity(0, 1) ENCODE DELTA,
state DOUBLE PRECISION ENCODE Runlength,
zipcode REAL,
tempdel1 DECIMAL ENCODE Mostly16,
tempdel2 BIGINT ENCODE Mostly32,
tempdel3 DATE ENCODE DELTA32k,
tempdel4 TIMESTAMP ENCODE Runlength,
tempdel5 TIMESTAMPTZ ENCODE DELTA,
tempdel6 VARCHAR(MAX) ENCODE text32k,
start_date VARCHAR(10) ENCODE TEXT255
)
DISTSTYLE KEY
DISTKEY (custname)
INTERLEAVED SORTKEY (custkey, custname);
CREATE TABLE
t3=# \d customer
TABLE "public.customer"
Column | Type | Encoding | DistKey | SortKey | Preload | Encryption | Collation | Nullable | Default
------------+-----------------------------+-----------+---------+---------+---------+------------+-----------+----------+------------------------------------
custkey | smallint | delta | f | 1 | f | none | | not null |
custname | integer | none | t | 2 | f | none | | | 10
gender | boolean | none | f | 0 | f | none | | |
address | character(5) | lzo | f | 0 | f | none | | |
city | bigint | delta | f | 0 | f | none | | | "identity"(493983, 4, '0,1'::text)
state | double precision | runlength | f | 0 | f | none | | |
zipcode | real | none | f | 0 | f | none | | |
tempdel1 | numeric(18,0) | mostly16 | f | 0 | f | none | | |
tempdel2 | bigint | mostly32 | f | 0 | f | none | | |
tempdel3 | date | delta32k | f | 0 | f | none | | |
tempdel4 | timestamp without time zone | runlength | f | 0 | f | none | | |
tempdel5 | timestamp with time zone | delta | f | 0 | f | none | | |
tempdel6 | character varying(65535) | text32k | f | 0 | f | none | | |
start_date | character varying(10) | text255 | f | 0 | f | none | | |
12 Aug 2017
Redshift support for psql
Am sure you know that psql doesn't go out of it's way to support Postgres' forks natively. I obviously understand the reasoning, which allowed me to find a gap that I could fill here.
The existing features (in psql) that work with any Postgres fork (like Redshift) are entirely because it is a fork of Postgres. Since I use psql heavily at work, last week I decided to begin maintaining a Postgres fork that better supports (Postgres forks, but initially) Redshift. As always, unless explicitly mentioned, this is entirely an unofficial effort.
The 'redshift' branch of this Postgres code-base, is aimed at supporting Redshift in many ways:
The idea is:
Update (31st August 2017)
The existing features (in psql) that work with any Postgres fork (like Redshift) are entirely because it is a fork of Postgres. Since I use psql heavily at work, last week I decided to begin maintaining a Postgres fork that better supports (Postgres forks, but initially) Redshift. As always, unless explicitly mentioned, this is entirely an unofficial effort.
The 'redshift' branch of this Postgres code-base, is aimed at supporting Redshift in many ways:
- Support Redshift related artifacts
- Redshift specific SQL Commands / variations
- Redshift Libraries
- Support AWS specific artifacts
- For e.g. AWS Regions
- Support Redshift specific changes
- For e.g. "/d table" etc.
The idea is:
- Maintain this branch for the long-term
- At least as long as I have an accessible Redshift cluster
- Down the line look at whether other Postgres forks (for e.g. RDS Postgres) need such special attention
- Although nothing much stands out yet
- Change the default port to 5439 (or whatever the flavour supports)
- ...with an evil grin ;)
- Additionally, as far as possible:
- Keep submitting Postgres related patches back to Postgres master
- Keep this branch up to date with Postgres master
Update (31st August 2017)
- Currently this branch supports most Redshift specific SQL commands such as
- CREATE LIBRARY
- CREATE TABLE (DISTKEY / DISTSTYLE / ...)
- Returns non-SQL items like
- ENCODINGs (a.k.a. Compressions like ZSTD / LZO etc )
- REGIONs (for e.g. US-EAST-1 etc.)
- Of course some complex variants (for e.g. GRANT SELECT, UPDATE ON ALL TABLES IN SCHEMA TO GROUP xxx ) don't automatically come up with tab-complete feature. This is primarily because psql's tab-complete feature isn't very powerful to cater to all such scenarios which in turn is because psql's auto-complete isn't a full-fledged parser to begin with.
- In a nutshell, this branch is now in a pretty good shape to auto-complete the most common Redshift specific SQL Syntax.
- The best part is that this still merges perfectly with Postgres mainline!
Let me know if you find anything that needs inclusion, or if I missed something.
====================================
$ psql -U redshift_user -h localhost -E -p 5439 db
psql (client-version:11devel, server-version:8.0.2, engine:redshift)
Type "help" for help.
db=#
====================================
$ psql -U redshift_user -h localhost -E -p 5439 db
psql (client-version:11devel, server-version:8.0.2, engine:redshift)
Type "help" for help.
db=#
31 May 2017
Patch: Using --no-comments with pg_dump
Recently I submitted a patch for review that allows a non-superuser to practically use a backup taken from pg_dump.
Currently it is a kludge (and well known at that - Ref 1 / Ref 2 / Ref 3 / Ref 4) but since it's (the ideal solution) too big a byte to chew and not in high-demand, it has seen little to no traction in the past decade.
This patch should allow the above. But more importantly, it should also allow regular users of AWS RDS Postgres as well as Google Cloud Postgres databases (who do not get SuperUser access by-design) to reliably use the backups, instead of tinkering with the backup SQLs and remove things like COMMENT ON EXTENSION for it to even run during restoration.
The bad news is that since Postgres 10 has already branched off, I doubt this would see the light of the day (if at all) any time before Postgres 11 (unless there is consensus that it's helpful enough and gets 'back-patched' to Postgres 10 to be released around September 2017).
Update (3rd Oct 2017):
This is now a part of my PsqlForks branch. You can check the related commit here.
Update (26th Jan 2018):
This is now part of the official Postgres v11 branch. You can check the related commit here.
Currently it is a kludge (and well known at that - Ref 1 / Ref 2 / Ref 3 / Ref 4) but since it's (the ideal solution) too big a byte to chew and not in high-demand, it has seen little to no traction in the past decade.
This patch should allow the above. But more importantly, it should also allow regular users of AWS RDS Postgres as well as Google Cloud Postgres databases (who do not get SuperUser access by-design) to reliably use the backups, instead of tinkering with the backup SQLs and remove things like COMMENT ON EXTENSION for it to even run during restoration.
The bad news is that since Postgres 10 has already branched off, I doubt this would see the light of the day (if at all) any time before Postgres 11 (unless there is consensus that it's helpful enough and gets 'back-patched' to Postgres 10 to be released around September 2017).
Update (3rd Oct 2017):
This is now a part of my PsqlForks branch. You can check the related commit here.
Update (26th Jan 2018):
This is now part of the official Postgres v11 branch. You can check the related commit here.
horntail it is :)
I had been planning to contribute to Postgres Buildfarm by running it on one of my VMs and finally got that done... and horntail it is.
A few things to note, before it fades from (my) memory:
A few things to note, before it fades from (my) memory:
- It (obviously) requires quite a bunch of libraries, especially if you're using the defaults (for e.g. with ssl / krb5 etc..)
- You may either disable some of those exotic options (not ideally recommended)
- Or, you may use a silo'ed VM just for this purpose so that it doesn't slow your regular work
- I did neither (of the above) but didn't care about performance of this VM
- Probably would enable more Options / Branches down the line and re-submit
- My distro was Ubuntu and so YMMV, but the packages weren't very obvious. If you see something fail and you check logs, you'd see that 'abc' was missing, but wouldn't have the faintest idea which package satisfied that
- Some hiccup missing libraries were (These may be obvious for most, but were new to me ):
- gss_init_sec_context
- msgfmt
- tclConfig
- It'd be good if someone could catalog the packages required
- For all Unix variants - obviously easier said that done, but
- It's possible that there may be more people willing (like me) but unable to scale all the walls
- At least the super-set of what's required when all flags are enabled, from which people could try what's needed for his / her set of enabled flags
- As it always is, the documentation is relatively clear, just that persistence (especially for exotic Linux variants / issues) is needed in large quantities.
All the best :)
8 Mar 2017
Using pg_dumpall with AWS RDS Postgres
My patch (allowing a non-super-user to dump Globals) just got committed to Postgres 10.0.
Besides the use mentioned above, this patch allows one to dump Globals from their AWS RDS Postgres Database and have a complete backup as a part of their Disaster Recovery (DR) solution. This earlier required an inelegant hack (detailed here in another post of mine) that wasn't very convenient for a regular user.
For those interested, RDS Postgres (by design) doesn't allow you to read pg_authid, which was earlier necessary for pg_dumpall to work. With this patch checked-in, pg_dumpall now uses a workaround (pg_roles) to read the same data (except passwords) and generate the same SQL Script.
With that mentioned, let's get our hands dirty and see a working solution:
# Take RDS Postgres Dump
# We store the pgdb database in pgdb.sql and globals in pgdb_globals.sql
pg_dumpall --globals-only --no-role-passwords \
-U rdssuperuser -h rdsinstance \
2>stderr.txt > pgdb_globals.sql
pg_dump -U rdssuperuser -h rdsinstance pgdb 2>stderr.txt > pgdb.sql
# Restore on Local Machine
psql -U postgres -c "CREATE DATABASE pgdb;"
# rdsadmin database (even if empty) is required for the next script
psql -U postgres -c "CREATE DATABASE rdsadmin;"
psql -U postgres pgdb < pgdb_globals.sql
psql -U postgres pgdb < pgdb.sql
Note: The --no-role-passwords flag is still necessary since AWS RDS doesn't allow you to read Passwords. Therefore, the above generates a script that resets all users to be password-less, but that's still better than having to restore Globals (like 'CREATE USER ... ') manually by hand!
Big thanks to Simon for ironing out a few issues, Stephen, David & Robert for their (critical) reviews.
Besides the use mentioned above, this patch allows one to dump Globals from their AWS RDS Postgres Database and have a complete backup as a part of their Disaster Recovery (DR) solution. This earlier required an inelegant hack (detailed here in another post of mine) that wasn't very convenient for a regular user.
For those interested, RDS Postgres (by design) doesn't allow you to read pg_authid, which was earlier necessary for pg_dumpall to work. With this patch checked-in, pg_dumpall now uses a workaround (pg_roles) to read the same data (except passwords) and generate the same SQL Script.
With that mentioned, let's get our hands dirty and see a working solution:
# Take RDS Postgres Dump
# We store the pgdb database in pgdb.sql and globals in pgdb_globals.sql
pg_dumpall --globals-only --no-role-passwords \
-U rdssuperuser -h rdsinstance \
2>stderr.txt > pgdb_globals.sql
pg_dump -U rdssuperuser -h rdsinstance pgdb 2>stderr.txt > pgdb.sql
psql -U postgres -c "CREATE DATABASE pgdb;"
# rdsadmin database (even if empty) is required for the next script
psql -U postgres -c "CREATE DATABASE rdsadmin;"
psql -U postgres pgdb < pgdb_globals.sql
psql -U postgres pgdb < pgdb.sql
Big thanks to Simon for ironing out a few issues, Stephen, David & Robert for their (critical) reviews.
12 Nov 2015
Pigz - Parallel GZip
For a while, I've been frustrated with the fact that GZip was unable to consume idle CPUs on my laptop. Recently read about PIGZ (a drop-in GPL replacement) that implicitly consumes all CPUs.
Pronounced Pig-Zee, PIGZ is a drop-in replacement for GZIP and automatically consumes all CPUs of the host machine in order to get the compression completed much faster.
OLD: tar -cf - sourcefolder | gzip > sourcefolder.tar.gz
NEW: tar -cf - sourcefolder | pigz > sourcefolder.tar.gz
Enjoy!
Pronounced Pig-Zee, PIGZ is a drop-in replacement for GZIP and automatically consumes all CPUs of the host machine in order to get the compression completed much faster.
OLD: tar -cf - sourcefolder | gzip > sourcefolder.tar.gz
NEW: tar -cf - sourcefolder | pigz > sourcefolder.tar.gz
Enjoy!
Subscribe to:
Comments (Atom)
-
(Please scroll down to the read the entire-post to know more) Documents required for Christian Marriage Registration (a.k.a. Documents...
-
After moving to Hyderabad last year, I had to bring my (Delhi Registered) car to Hyderabad for regular day-to-day use. Coupled with the fac...
-
A recent commit to the PostgreSQL master branch brings a nice quality-of-life optimization for a very common SQL pattern - improving perform...