Re: [GENERAL] Corrupted Data ?
Hi Adrian: On Fri, Aug 12, 2016 at 9:01 PM, Adrian Klaver wrote: > "Specially if this happens, you may have some slightly bad disks/ram/ > leading to this kind of problems." > > Trying to reconcile that with all the physical machine 1 VMs sharing the > same RAM and physical disk, but the error only occurring on db3. > > Is the VM hosting db3 setup different from the VMs 1 & 2? They probably share the disk, bus, ram and disk controllers, but they surely do not share the disk SECTORS. "Weak" ( nearly failing ) tracks can give this kind of problems ( although the disk CRC should catch all odd number of bit errors , but with VMs in the mix who knows where the messages could end up ). Francisco Olarte. -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Any reasons for 'DO' statement not returning result?
On Fri, Aug 12, 2016 at 11:34 PM, Xtra Coder wrote: ... > In my particular case I'm more interested in an easy way to create complex > SELECTs that require usage of variables in the one-time through-away scripts > (some-time during experiments for implementation of functions, to see > immediate results of the intermediate code). The easiest way would be > MsSQL-like when declaring a variable outside of SP actually makes it visible > globally in current session. In such case I do not need 'DO' at all and this > is simple. Probably PostgreSQL has another way to make that thing simple. If you are just interested in avoiding some mistakes, and/or parametrizing some queries from the command line, psql ( the CLI program ) has macro expansion with some sql quoting capabilities, see https://www.postgresql.org/docs/9.5/static/app-psql.html#APP-PSQL-VARIABLES and be sure to scroll down to "SQL Interpolation" after the built in variables list and read that. I've used it several times, just remember it's a macro processor and it's done by psql, not by the server. Francisco Olarte. -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] BDR Cluster vs DB Config
El 20/07/16 a las 20:06, Jonathan Eastgate escribió: > > I assume that once BDR is enabled on a database that any additional > schemas added post config are automatically included in BDR replication? All DDLs (CREATE SCHEMA ...) will be replicated to the other nodes, but if you are asking if the data from newly created tables will automatically start replicating, that depends on how you initially configured your replication sets. The short answer is, the default is to replicate all tables, new ones included. But if you plan on doing selective replication by creating a replication set and adding tables there, then it's on you to add or not the new tables to that set. > And so you see any issues having potentially 200 schemas within the DB - > performance or replication wise? I don't see any possible performance degradation just for having the tables spread in different schemata. There will be one walsender for each downstream node, and one apply worker for each upstream node, so you literally cut down to 1/200 the amount of replication slots and replication connections on each node. That's a huge performance win, particularly on 9.4. Regards, -- Martín Marquéshttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Postgres Pain Points: 1 pg_hba conf
On 8/13/2016 8:29 AM, support-tiger wrote: experimented with this some more with no progress. only trust seems to work which is not what we want - will try some more versions with md5 but this is why I've called this out as such a pain point. show us your pg_hba.conf (sans comments), and the connections that aren't working the way you want, along with whatever error messages they are generating. -- john r pierce, recycling bits in santa cruz -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Postgres Pain Points: 1 pg_hba conf
On Sat, Aug 13, 2016 at 9:37 PM, John R Pierce wrote: > On 8/13/2016 8:29 AM, support-tiger wrote: > >> experimented with this some more with no progress. only trust seems to >> work which is not what we want - will try some more versions with md5 but >> this is why I've called this out as such a pain point. >> > > show us your pg_hba.conf (sans comments), and the connections that aren't > working the way you want, along with whatever error messages they are > generating. It's worth noting how I normally set up this file: 1. Set up postgres user on local connections with peer authentication 2. Set up initial roles, passwords, etc. (sudo -u postgres psql, then create role ... with noinherit login password = ...) 3. Configure for MD5 auth over the network and for all users on local except postgres. Of course that differs depending on environment and requirements but it is a decent starting point. > > > > > -- > john r pierce, recycling bits in santa cruz > > > > -- > Sent via pgsql-general mailing list (pgsql-general@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-general > -- Best Wishes, Chris Travers Efficito: Hosted Accounting and ERP. Robust and Flexible. No vendor lock-in. http://www.efficito.com/learn_more
