Re: [GENERAL] password in recovery.conf [SOLVED]
On Fri, Sep 26, 2014 at 6:46 PM, Adrian Klaver wrote: > On 09/26/2014 04:32 PM, Nelson Green wrote: > >> On Fri, Sep 26, 2014 at 5:51 PM, Adrian Klaver >> > > Doubling the quote seems to work here. >> >> >> Thanks Bosco, DrakoRod, and Adrian. Between the three of you it became >> obvious >> that I was doing something wrong. And yes, in the end you were right. >> Doubling >> the quote does indeed work. >> >> It turns out it this particular password also had a \ in it, and my >> console >> width wrapped right before it, putting it as the first character on the >> next >> line, where I just didn't notice it until a few minutes ago. I changed >> that to >> a ^ for the time being, and then doubled the quote whereupon it all >> worked. I >> will certainly look into how to escape the backslash too, but that's for >> next >> week at this point. >> > > aklaver@panda:~> psql 'dbname=test user=test_user password=test\\pwd' > psql (9.0.17) > Type "help" for help. > > test=> Thanks again Adrian! Figures it's that easy. Confession time. When I'm trying to work through something like this where different iterations are going to be tried, I sit down and spell them out first. But since I was remoted in and things were going so slow (and I was pretty tired), I just tried different combinations on the single quote. When I noticed the backslash I tried to double it, but with no luck. However, in all honesty I don't know what I was doing with the single quote at that particular moment. Bottom line is I probably shot myself in the foot in several ways with this one. I appreciate the patience with me. Nelson
Re: [GENERAL] password in recovery.conf [SOLVED]
On Fri, Sep 26, 2014 at 6:40 PM, John R Pierce wrote: > On 9/26/2014 4:32 PM, Nelson Green wrote: > >> >> Thanks Bosco, DrakoRod, and Adrian. Between the three of you it became >> obvious >> that I was doing something wrong. And yes, in the end you were right. >> Doubling >> the quote does indeed work. >> >> It turns out it this particular password also had a \ in it, and my >> console >> width wrapped right before it, putting it as the first character on the >> next >> line, where I just didn't notice it until a few minutes ago. I changed >> that to >> a ^ for the time being, and then doubled the quote whereupon it all >> worked. I >> will certainly look into how to escape the backslash too, but that's for >> next >> week at this point. >> > > I'd consider using `mkpasswd -l 15 -s 0` just to avoid any such > problems. 15 random alphanumerics is already plenty complex, 62^15th > possible combinations, without needing to mix in special characters. > > $ mkpasswd -l 15 -s 0 > eec1kj7ZsthlYmh > Thanks John. We use apg which has similar options. But alas, I must comply with organizational password policies. Regards, Nelson
[GENERAL] Postgres as key/value store
I'm looking for some feedback on the design I'm using for a basic key/value storage using postgres. Just some quick background. This design is for large scale games that can get up to 10K writes per second or more. The storage will be behind a distributed memory cache that is built on top of Akka, and has a write behind caching mechanism to cut down on the number of writes when you have many updates in a short time period of the same key, which is common for a lot of multiplayer type games. I have been using Couchbase, but this is an open source project, and Couchbase is basically a commercial product for all intents and purposes, which is problematic. I will still support Couchbase, but I don't want it have to tell people if you really want to scale, couchbase is the only option. The schema is that a key is a string, and the value is a string or binary. I am actually storing protocol buffer messages, but the library gives me the ability to serialize to native protobuf or to json. Json is useful at times especially for debugging. This is my current schema: CREATE TABLE entities ( id character varying(128) NOT NULL, value bytea, datatype smallint, CONSTRAINT entities_pkey PRIMARY KEY (id) ); CREATE OR REPLACE RULE entities_merge AS ON INSERT TO entities WHERE (EXISTS ( SELECT 1 FROM entities entities_1 WHERE entities_1.id::text = new.id::text)) DO INSTEAD UPDATE entities SET value = new.value, datatype = new.datatype WHERE entities.id::text = new.id::text; Additional functionality I want is to do basic fuzzy searches by key. Currently I'm using a left anchored LIKE query. This works well because keys are left prefixed with a scope, a delimiter, and then the actual key for the data. These fuzzxy searches would never be used in game logic, they would be admin only queries for doing things like obtaining a list of players. So they should be infrequent. The scope of the query ability will not expand in the future. I support multiple backends for the key/value storage so I'm working with the lowest common denominator. Plus I have a different approach for data that you need to do complex queries on (regular tables and an ORM). Chris
Re: [GENERAL] Postgres as key/value store
On 28/09/14 12:48, snacktime wrote: I'm looking for some feedback on the design I'm using for a basic key/value storage using postgres. Just some quick background. This design is for large scale games that can get up to 10K writes per second or more. The storage will be behind a distributed memory cache that is built on top of Akka, and has a write behind caching mechanism to cut down on the number of writes when you have many updates in a short time period of the same key, which is common for a lot of multiplayer type games. I have been using Couchbase, but this is an open source project, and Couchbase is basically a commercial product for all intents and purposes, which is problematic. I will still support Couchbase, but I don't want it have to tell people if you really want to scale, couchbase is the only option. The schema is that a key is a string, and the value is a string or binary. I am actually storing protocol buffer messages, but the library gives me the ability to serialize to native protobuf or to json. Json is useful at times especially for debugging. This is my current schema: CREATE TABLE entities ( id character varying(128) NOT NULL, value bytea, datatype smallint, CONSTRAINT entities_pkey PRIMARY KEY (id) ); CREATE OR REPLACE RULE entities_merge AS ON INSERT TO entities WHERE (EXISTS ( SELECT 1 FROM entities entities_1 WHERE entities_1.id::text = new.id::text)) DO INSTEAD UPDATE entities SET value = new.value, datatype = new.datatype WHERE entities.id::text = new.id::text; Additional functionality I want is to do basic fuzzy searches by key. Currently I'm using a left anchored LIKE query. This works well because keys are left prefixed with a scope, a delimiter, and then the actual key for the data. These fuzzxy searches would never be used in game logic, they would be admin only queries for doing things like obtaining a list of players. So they should be infrequent. The scope of the query ability will not expand in the future. I support multiple backends for the key/value storage so I'm working with the lowest common denominator. Plus I have a different approach for data that you need to do complex queries on (regular tables and an ORM). Chris Note: I suspect that what I suggest below will probably NOT improve performance, and may not necessarily be appropriate for your use case. However, they may facilitate a wider range of queries, and might be easier to understand. Note the comment about using 'PRIMARY KEY' in http://www.postgresql.org/docs/9.2/static/sql-createtable.html [...] The primary key constraint specifies that a column or columns of a table can contain only unique (non-duplicate), nonnull values. Technically, PRIMARY KEY is merely a combination of UNIQUE and NOT NULL, but identifying a set of columns as primary key also provides metadata about the design of the schema, as a primary key implies that other tables can rely on this set of columns as a unique identifier for rows. [...] My first thought was to simplify the table create, though I think the length check on the id is best done in the software updating the databased: CREATE TABLE entities ( id text PRIMARY KEY, value bytea, datatype smallint, CONSTRAINT id_too_long CHECK (length(id) <= 128) ); Then I noticed that your id is actually a compound key, and probably would be better modelled as: CREATE TABLE entities ( scope text, keytext, value bytea, datatype smallint, CONSTRAINT entities_pkey PRIMARY KEY (scope, key) ); I suspect that making 'datatype' an 'int' would improve performance, but only by a negligible amount! Cheers, Gavin
