Re: [GENERAL] BDR Cluster vs DB Config

Hello. BDR works on a per-database basis, so there's nothing like what you are looking for. However, if you initialize a BDR custer with bdr_init_copy, you will get all existing databases added to replication. Then, as part of the creation of new databases, you can use bdr_group_join function,

[GENERAL] BDR Cluster vs DB Config

Hi everyone. We've been testing BDR on and off for the last 2 years and are keen to start looking at implementing it in production as it seems 0.93 has resolved most of the issues we faced with it in the early days. However there is still one item that makes it a difficult proposition... DSN

Re: [GENERAL] Is it possible to control the location of the lock file when starting postgres?

On 7/19/2016 3:35 PM, Steve Langlois wrote: >Presumably, you are working with a distro-modified version of Postgres, >because the stock sources don't use /var/run/postgresql as a socket >directory. You will likely find that your version of libpq.so also >expects /var/run/postgresql as the

Re: [GENERAL] Is it possible to control the location of the lock file when starting postgres?

>Presumably, you are working with a distro-modified version of Postgres, >because the stock sources don't use /var/run/postgresql as a socket >directory. You will likely find that your version of libpq.so also >expects /var/run/postgresql as the socket directory, so you won't be >able to make

[GENERAL] Re: Is it possible to control the location of the lock file when starting postgres?

My apologies but I didn't include the command I am using to start the database /usr/bin/postmaster -p 5432 -D /usr//databases/pgsql/data FATAL: could not create lock file "/var/run/postgresql/.s.PGSQL.5432.lock": Permission denied Thank you.

Re: [GENERAL] Is it possible to control the location of the lock file when starting postgres?

Steve Langlois writes: > I ran > + /usr/bin/initdb --pgdata=/usr/xxx/databases/pgsql/data --auth=ident > without issue however when I try to start the database it complains about the > lockfile. > FATAL: could not create lock file

Re: [GENERAL] Is it possible to control the location of the lock file when starting postgres?

On 07/19/2016 02:49 PM, Steve Langlois wrote: Using Postgres 9.2 with CentOS7. I ran + /usr/bin/initdb --pgdata=/usr/xxx/databases/pgsql/data --auth=ident without issue however when I try to start the database it complains about the lockfile. FATAL: could not create lock file

[GENERAL] Is it possible to control the location of the lock file when starting postgres?

Using Postgres 9.2 with CentOS7. I ran + /usr/bin/initdb --pgdata=/usr/xxx/databases/pgsql/data --auth=ident without issue however when I try to start the database it complains about the lockfile. FATAL: could not create lock file "/var/run/postgresql/.s.PGSQL.5432.lock": Permission

Re: [GENERAL] upsert with trigger (or rule)

On 07/19/2016 01:25 PM, Maeldron T. wrote: Hello Adrian, On 19/07/16 21:27, Adrian Klaver wrote: On 07/19/2016 11:56 AM, Maeldron T. wrote: By returning NULL in your function you are skipping the original INSERT. I know that, I wrote it. I am sure exactly what you are trying to

Re: [GENERAL] PostgreSQL GUI tools

Hi Subhan, Sorry for the quite late reply, but just in case you're still looking for a proper GUI - you may want to check out our latest Mac OS GUI for PostgreSQL at http://sequel.tech We're just about to release it and is probably the best Mac GUI for PostgreSQL now. Let me know if I can help

Re: [GENERAL] MongoDB 3.2 beating Postgres 9.5.1?

Hi, I recently test YCSB benchmark too. But contrary to my expectation, PG (9.5) is slower than MongoDB 3.2. Paul said that making table with no logging option improved the performance, and it might be equal to MongoDB's behavior. But in MongoDB documentation, it writes journal log too. So I think

[GENERAL] Cancel post: FW: Unix Postgres 9.5. using pg_basebackup and WAL files. Can't get a PITR recovery

Sorry. It miraculously started working! My problem is gone. From: Pruett, Jennis Sent: Friday, July 15, 2016 11:10 AM To: 'pgsql-general@postgresql.org' Subject: Unix Postgres 9.5. using pg_basebackup and WAL files. Can't get a PITR recovery I can't cut and paste my issues, so I will explain

[GENERAL] Unix Postgres 9.5. using pg_basebackup and WAL files. Can't get a PITR recovery

I can't cut and paste my issues, so I will explain as best I can. I'm testing PITR on a single 9.5 db (no replication setups). I have all the settings that I can find, wal_level, archive_command, restore_command, directories defined, logs defined. My WAL files are stored off in another area

Re: [GENERAL] pg_restore out of memory

A Qui, 14-07-2016 às 10:52 +0100, Miguel Ramos escreveu: > > A Qua, 13-07-2016 às 18:42 -0400, Tom Lane escreveu: > > > > I wrote: > > > > > > I'm still suspicious that this might be some sort of NOTICE- > > > processing- > > > related buffer bloat.  Could you try loading the data with the > >

Re: [GENERAL] upsert with trigger (or rule)

Hello Adrian, On 19/07/16 21:27, Adrian Klaver wrote: On 07/19/2016 11:56 AM, Maeldron T. wrote: By returning NULL in your function you are skipping the original INSERT. I know that, I wrote it. I am sure exactly what you are trying to achieve, In general, there are the

Re: [GENERAL] upsert with trigger (or rule)

On 07/19/2016 11:56 AM, Maeldron T. wrote: Hello, I’m trying to rewrite inserts to upserts on a table when a certain column has a certain value. Reason: the inserts are coming from an ORM. It’s possible to send upsert from the ORM, however, in this case I find it more elegant and

[GENERAL] upsert with trigger (or rule)

Hello, I’m trying to rewrite inserts to upserts on a table when a certain column has a certain value. Reason: the inserts are coming from an ORM. It’s possible to send upsert from the ORM, however, in this case I find it more elegant and future-proof to deal with it at the DB

Re: [GENERAL] Constraint using a SQL function executed during SELECT

"Cyril B." writes: > On 07/19/2016 03:51 PM, Jim Nasby wrote: >> In this example, you should be able to avoid that by setting >> constraint_exclusion=off. > Sorry I forgot to mention I had already tried that, to no avail. Yeah, constraint_exclusion won't help, because this

Re: [GENERAL] MediaWiki + PostgreSQL is not ready for production?

-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 Tatsuo Ishii wrote: > "Anything other than MySQL or MariaDB is not recommended for > production use at this point." > > This is a sad and disappointed statement for us. It's more of a labelling problem than anything else at this point.

Re: [GENERAL] Constraint using a SQL function executed during SELECT

On 07/19/2016 03:51 PM, Jim Nasby wrote: In this example, you should be able to avoid that by setting constraint_exclusion=off. Sorry I forgot to mention I had already tried that, to no avail. -- Cyril B. -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes

Re: [GENERAL] Constraint using a SQL function executed during SELECT

On 7/19/16 7:43 AM, Cyril B. wrote: Hello, Is there a way to execute a SELECT on a table having a constraint that uses a non-working SQL function? ... ALTER TABLE ONLY t1 ADD CONSTRAINT c EXCLUDE (id WITH =) WHERE ((f(id) IS NOT TRUE)); ... ERROR: relation "rename_me.t2" does not exist

Re: [GENERAL] MediaWiki + PostgreSQL is not ready for production?

On 07/19/2016 12:20 AM, Tatsuo Ishii wrote: On 7/18/2016 9:14 PM, Tatsuo Ishii wrote: My colleague has been working on making the latest version of WordPress work with PostgreSQL (there used be a PostgreSQL plugin but it has not been maintained and does not work with the latest version of

Re: [GENERAL] MongoDB 3.2 beating Postgres 9.5.1?

On Tuesday, July 19, 2016 6:19 AM, Teodor Sigaev wrote: > CREATE INDEX json_tables_idx ON json_tables USING GIN (data jsonb_path_ops); > Bitmap Heap Scan on json_tables  (cost=113.50..37914.64 rows=1 width=1261) > (actual time=2157.118..1259550.327 rows=909091

Re: [GENERAL] MongoDB 3.2 beating Postgres 9.5.1?

On Monday, July 18, 2016 10:14 PM, Kisung Kim wrote: Hi,I recently test YCSB benchmark too.But contrary to my expectation, PG (9.5) is slower than MongoDB 3.2.Paul said that making table with no logging option improved the performance,and it might be equal to

[GENERAL] Constraint using a SQL function executed during SELECT

Hello, Is there a way to execute a SELECT on a table having a constraint that uses a non-working SQL function? I know the easiest way would be to fix the function, but I'm the database administrator, not the owner, and I need to do a COUNT(*) on each table. Here's a minimal use case:

Re: [GENERAL] MongoDB 3.2 beating Postgres 9.5.1?

CREATE INDEX json_tables_idx ON json_tables USING GIN (data jsonb_path_ops); Bitmap Heap Scan on json_tables (cost=113.50..37914.64 rows=1 width=1261) (actual time=2157.118..1259550.327 rows=909091 loops=1) Recheck Cond: (data @> '{"name": "AC3 Case Red"}'::jsonb) Rows Removed by

Re: [GENERAL] MediaWiki + PostgreSQL is not ready for production?

On Tue, Jul 19, 2016 at 12:55:09PM +0300, Achilleas Mantzios wrote: > It seems we have made already a verdict about mysql's code migrated to > PostgreSQL being slow Experience with designed-for-MySQL code that is modified to go through a so-called abstraction layer suggests that it will be.

Re: [GENERAL] MediaWiki + PostgreSQL is not ready for production?

On 19/07/2016 12:41, Andrew Sullivan wrote: On Tue, Jul 19, 2016 at 12:37:10PM +0300, Achilleas Mantzios wrote: Better to run, even slowly, than not run at all, or require special porting team for every mysql client out there. I'm not sure I agree. If you teach every naïve user that, when

Re: [GENERAL] pglogical cascading replication (chaining replication)

The solution was found thanks to Petr Jelinek from 2ndQ. > Cascading wasn't much of a priority so far. > Currently you have to create the origin manually using > pg_replication_origin_create(). > I plan to make this work seamlessly in the future release. So whats needed to be done is: on p2:

Re: [GENERAL] pglogical cascading replication (chaining replication)

The solution was found thanks to Petr Jelinek from 2ndQ. > Cascading wasn't much of a priority so far. > Currently you have to create the origin manually using > pg_replication_origin_create(). > I plan to make this work seamlessly in the future release. So whats needed to be done is: on p1:

Re: [GENERAL] MediaWiki + PostgreSQL is not ready for production?

On Tue, Jul 19, 2016 at 12:37:10PM +0300, Achilleas Mantzios wrote: > > Better to run, even slowly, than not run at all, or require special porting > team for every mysql client out there. > I'm not sure I agree. If you teach every naïve user that, when they compare Postgres to MySQL, MySQL

Re: [GENERAL] MediaWiki + PostgreSQL is not ready for production?

On 19/07/2016 12:05, Tatsuo Ishii wrote: My colleague has been working on making the latest version of WordPress work with PostgreSQL (there used be a PostgreSQL plugin but it has not been maintained and does not work with the latest version of WordPress). I imagine there are someone who are

Re: [GENERAL] MediaWiki + PostgreSQL is not ready for production?

>> My colleague has been working on making the latest version of >> WordPress >> work with PostgreSQL (there used be a PostgreSQL plugin but it has not >> been maintained and does not work with the latest version of >> WordPress). I imagine there are someone who are attacking the classic >>

Re: [GENERAL] MediaWiki + PostgreSQL is not ready for production?

John R Pierce wrote: On 7/18/2016 9:14 PM, Tatsuo Ishii wrote: I found following comment for using PostgreSQL with MediaWiki: https://www.mediawiki.org/wiki/Compatibility#Database "Anything other than MySQL or MariaDB is not recommended for production use at this point." This is a sad and

Re: [GENERAL] MediaWiki + PostgreSQL is not ready for production?

On 19/07/2016 10:20, Tatsuo Ishii wrote: On 7/18/2016 9:14 PM, Tatsuo Ishii wrote: I found following comment for using PostgreSQL with MediaWiki: https://www.mediawiki.org/wiki/Compatibility#Database "Anything other than MySQL or MariaDB is not recommended for production use at this point."

Re: [GENERAL] MediaWiki + PostgreSQL is not ready for production?

> On 7/18/2016 9:14 PM, Tatsuo Ishii wrote: >> I found following comment for using PostgreSQL with MediaWiki: >> >> https://www.mediawiki.org/wiki/Compatibility#Database >> >> "Anything other than MySQL or MariaDB is not recommended for >> production use at this point." >> >> This is a sad and