Commit Graph

14 Commits

Author SHA1 Message Date
Devin Christensen b0f50ecb6c Remove prepared stmnts from pgsql physical backend
Prepared statements prevent the use of connection multiplexing software
such as PGBouncer. Even when PGBouncer is configured for [session mode][1]
there's a possibility that a connection to PostgreSQL can be re-used by
different clients.  This leads to errors when clients use session based
features (like prepared statements).

This change removes prepared statements from the PostgreSQL physical
backend. This will allow vault to successfully work in infrastructures
that employ the use of PGBouncer or other connection multiplexing
software.

[1]: https://pgbouncer.github.io/config.html#poolmode
2016-05-26 17:07:21 -06:00
Sean Chittenden aeea7628d6 Add a *log.Logger argument to physical.Factory
Logging in the backend is a good thing.  This is a noisy interface change but should be a functional noop.
2016-04-25 20:10:32 -07:00
Sean Chittenden bd3335c1bd `go fmt` the PostgreSQL backend 2016-04-25 18:01:13 -07:00
Devin Christensen 4112809fb5 Make the PostgreSQL backend more performant 2016-01-29 13:47:10 -07:00
Devin Christensen 737df30939 Improve naming
Hopefully this naming scheme will be more straightforward.
2016-01-27 17:15:48 -07:00
Devin Christensen c226b0be7d Update naming and pull DDL for upsert back out 2016-01-22 17:15:10 -07:00
Devin Christensen 32b712ddb1 Move the upsert definition back into the code 2016-01-22 09:47:02 -07:00
Devin Christensen bfbdc72e03 Remove options for column configuration 2016-01-22 08:41:31 -07:00
Devin Christensen 06641570c7 Remove DDL statements from the code 2016-01-20 18:52:49 -07:00
Devin Christensen bcc720be11 Remove superfluous comparison 2016-01-20 17:05:21 -07:00
Devin Christensen 65bd200fae Ensure rows.Close() is called in List 2016-01-20 17:02:23 -07:00
Devin Christensen 614f7b7157 Prefer TEXT over VARCHAR
From the PostgreSQL docs
(http://www.postgresql.org/docs/9.4/static/datatype-character.html):

 > Tip: There is no performance difference among these three types,
 > apart from increased storage space when using the blank-padded type,
 > and a few extra CPU cycles to check the length when storing into a
 > length-constrained column. While character(n) has performance
 > advantages in some other database systems, there is no such advantage
 > in PostgreSQL; in fact character(n) is usually the slowest of the
 > three because of its additional storage costs. In most situations
 > text or character varying should be used instead.
2016-01-20 16:56:46 -07:00
Devin Christensen b4e9e204f7 Use native upsert when available 2016-01-20 10:47:54 -07:00
Devin Christensen fc94487f55 Add support for PostgreSQL as a physical backend 2016-01-19 17:00:09 -07:00