Re: [GENERAL] Moving a large DB (> 500GB) to another DB with different locale

2016-01-15 Thread Andreas Joseph Krogh 
På torsdag 14. januar 2016 kl. 00:34:51, skrev Jim Nasby <
jim.na...@bluetreble.com >:
On 1/13/16 2:39 PM, Andreas Joseph Krogh wrote:
 > Where can I find more info about how to use and configure pg_logical to
 > replicate a 9.4 DB to 9.5?

 http://2ndquadrant.com/en/resources/pglogical/
 
Thanks, I found detailed instructions in 
/usr/share/doc/postgresql-9.5-pglogical/README.md.gz
Any chance of putting in online?
 
I see that wal_level = 'logical', and that is a problem for us as we already 
use wal_level = 'hot_standby' on this installation as it replicates to another 
server.
 
Is it possible to use pglogical together with hot_standby 
streaming-replication?
 
Thank.
 
-- Andreas Joseph Krogh
CTO / Partner - Visena AS
Mobile: +47 909 56 963
andr...@visena.com 
www.visena.com 
 


 

Re: [GENERAL] Moving a large DB (> 500GB) to another DB with different locale

2016-01-15 Thread Andreas Joseph Krogh 
På fredag 15. januar 2016 kl. 14:33:24, skrev Shulgin, Oleksandr <
oleksandr.shul...@zalando.de >:
On Fri, Jan 15, 2016 at 1:02 PM, Andreas Joseph Krogh > wrote: På torsdag 14. januar 2016 kl. 00:34:51, 
skrev Jim Nasby >:
On 1/13/16 2:39 PM, Andreas Joseph Krogh wrote:
 > Where can I find more info about how to use and configure pg_logical to
 > replicate a 9.4 DB to 9.5?

http://2ndquadrant.com/en/resources/pglogical/ 

 
Thanks, I found detailed instructions in 
/usr/share/doc/postgresql-9.5-pglogical/README.md.gz
Any chance of putting in online?
 
I see that wal_level = 'logical', and that is a problem for us as we already 
use wal_level = 'hot_standby' on this installation as it replicates to another 
server.
 
Is it possible to use pglogical together with hot_standby 
streaming-replication?
 
Well, the wal_level change is just a matter of database restart: you got to do 
that once in a while anyway, e.g. for minor version updates.  I would expect 
you only need this wal_level on the walsender side, thus for pglogical_output, 
the logical decoding plugin.



 
My point is that we cannot not have streaming-replication, so we need to keep 
wal_level = 'hot_standby' AFAIU. Is there a way to do both streaming-replication
and pglogical for just replicating one of may databases in the same cluster?
 
-- Andreas Joseph Krogh
CTO / Partner - Visena AS
Mobile: +47 909 56 963
andr...@visena.com 
www.visena.com 
 


 

Re: [GENERAL] Moving a large DB (> 500GB) to another DB with different locale

2016-01-15 Thread Andreas Joseph Krogh 
På fredag 15. januar 2016 kl. 16:04:00, skrev Shulgin, Oleksandr <
oleksandr.shul...@zalando.de >:
On Fri, Jan 15, 2016 at 3:41 PM, Andreas Joseph Krogh > wrote: På fredag 15. januar 2016 kl. 14:33:24, 
skrev Shulgin, Oleksandr >:
On Fri, Jan 15, 2016 at 1:02 PM, Andreas Joseph Krogh > wrote:  
I see that wal_level = 'logical', and that is a problem for us as we already 
use wal_level = 'hot_standby' on this installation as it replicates to another 
server.
 
Is it possible to use pglogical together with hot_standby 
streaming-replication?
 
Well, the wal_level change is just a matter of database restart: you got to do 
that once in a while anyway, e.g. for minor version updates.  I would expect 
you only need this wal_level on the walsender side, thus for pglogical_output, 
the logical decoding plugin.



 
My point is that we cannot not have streaming-replication, so we need to keep 
wal_level = 'hot_standby' AFAIU. Is there a way to do both streaming-replication
and pglogical for just replicating one of may databases in the same cluster?
 
But logical is "greater than" hot_standby, so you can still have streaming 
replication with wal_level = logical.



 
This answers my initial question, thanks.
 
-- Andreas Joseph Krogh
CTO / Partner - Visena AS
Mobile: +47 909 56 963
andr...@visena.com 
www.visena.com 
 


 

Re: [GENERAL] Moving a large DB (> 500GB) to another DB with different locale

2016-01-15 Thread Shulgin, Oleksandr 
On Fri, Jan 15, 2016 at 1:02 PM, Andreas Joseph Krogh 
wrote:

> På torsdag 14. januar 2016 kl. 00:34:51, skrev Jim Nasby <
> jim.na...@bluetreble.com>:
>
> On 1/13/16 2:39 PM, Andreas Joseph Krogh wrote:
> > Where can I find more info about how to use and configure pg_logical to
> > replicate a 9.4 DB to 9.5?
>
> http://2ndquadrant.com/en/resources/pglogical/
>
>
> Thanks, I found detailed instructions in
> /usr/share/doc/postgresql-9.5-pglogical/README.md.gz
> Any chance of putting in online?
>
> I see that wal_level = 'logical', and that is a problem for us as we
> already use wal_level = 'hot_standby' on this installation as it replicates
> to another server.
>
> Is it possible to use pglogical together with hot_standby
> streaming-replication?
>

Well, the wal_level change is just a matter of database restart: you got to
do that once in a while anyway, e.g. for minor version updates.  I would
expect you only need this wal_level on the walsender side, thus for
pglogical_output, the logical decoding plugin.

--
Alex

Re: [GENERAL] Moving a large DB (> 500GB) to another DB with different locale

2016-01-15 Thread Shulgin, Oleksandr 
On Fri, Jan 15, 2016 at 3:41 PM, Andreas Joseph Krogh 
wrote:

> På fredag 15. januar 2016 kl. 14:33:24, skrev Shulgin, Oleksandr <
> oleksandr.shul...@zalando.de>:
>
> On Fri, Jan 15, 2016 at 1:02 PM, Andreas Joseph Krogh 
> wrote:
>>
>>
>> I see that wal_level = 'logical', and that is a problem for us as we
>> already use wal_level = 'hot_standby' on this installation as it replicates
>> to another server.
>>
>> Is it possible to use pglogical together with hot_standby
>> streaming-replication?
>>
>
> Well, the wal_level change is just a matter of database restart: you got
> to do that once in a while anyway, e.g. for minor version updates.  I would
> expect you only need this wal_level on the walsender side, thus for
> pglogical_output, the logical decoding plugin.
>
>
> My point is that we cannot not have streaming-replication, so we need to
> keep wal_level = 'hot_standby' AFAIU. Is there a way to do both
> streaming-replication *and* pglogical for just replicating one of may
> databases in the same cluster?
>

But logical is "greater than" hot_standby, so you can still have streaming
replication with wal_level = logical.

--
Alex

Re: [GENERAL] [BUGS] about test_parser installation failure problem(PostgreSQL in 9.5.0)？

2016-01-15 Thread Tom Lane 
"=?utf-8?B?6Zas6Zas44Kk44G1?="  writes:
>  test_parser install is ok (postgresql 9.2.4)
> but at (postgresql 9.5.0) failure？

Yes, we moved test_parser and some other only-useful-for-testing modules
from contrib to src/test/modules, which means they won't get installed in
standard installations.

regards, tom lane


-- 
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] WIP: CoC V7

2016-01-15 Thread Joshua D. Drake 

On 01/15/2016 09:03 AM, FarjadFarid(ChkNet) wrote:


Joshua and all,

Because of the current political environment we live in, even though I am 
neither a Muslim nor a Jew I am a Baha'i, I think we should not discuss 
religion or politics on this forum. All such topics can be discussed privately.


I am sure most agree with you but that isn't what a CoC is about. It is 
about "if" it happens, what is acceptable behaviour.


JD

--
Command Prompt, Inc.  http://the.postgres.company/
 +1-503-667-4564
PostgreSQL Centered full stack support, consulting and development.


--
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] WIP: CoC V7

2016-01-15 Thread Vick Khera 
On Fri, Jan 15, 2016 at 12:03 PM, FarjadFarid(ChkNet)
 wrote:
> Because of the current political environment we live in, even though I am 
> neither a Muslim nor a Jew I am a Baha'i, I think we should not discuss 
> religion or politics on this forum. All such topics can be discussed 
> privately.

Generally off-topic discussions are cut off pretty efficiently
already.  I think this CoC is more to the point of keeping things
civil while discussing the on-topic topics for each forum/list.


-- 
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] WIP: CoC V7

2016-01-15 Thread FarjadFarid(ChkNet) 

Joshua and all,

Because of the current political environment we live in, even though I am 
neither a Muslim nor a Jew I am a Baha'i, I think we should not discuss 
religion or politics on this forum. All such topics can be discussed privately. 

Thanks for your efforts. 

Best Regards


Farjad 


-Original Message-
From: pgsql-general-ow...@postgresql.org 
[mailto:pgsql-general-ow...@postgresql.org] On Behalf Of Joshua D. Drake
Sent: 15 January 2016 16:03
To: Neil; Psql_General (E-mail)
Subject: Re: [GENERAL] WIP: CoC V7

On 01/15/2016 07:41 AM, Joshua D. Drake wrote:
> tl;dr;
>
>   * Cleaned up first paragraph, making it more succint
>   * Reworded last bullet a bit
>
>
> == PostgreSQL Community Code of Conduct (CoC) ==
>
> This document provides community guidelines for a safe, respectful, 
> productive, and collaborative place for any person who is willing to 
> contribute to the PostgreSQL community. It applies to all 
> "collaborative space", which is defined as community communications 
> channels (such as mailing lists, IRC, submitted patches, commit comments, 
> etc.).
>
> * We are tolerant of people’s right to have opposing views.
>
> * Participants must ensure that their language and actions are free of 
> personal attacks and disparaging personal remarks.
>
> * When interpreting the words and actions of others, participants 
> should always assume good intentions.
>

* Participants who disrupt the collaborative space, or participate in a pattern 
of behaviour which could be considered harassment will not be tolerated.

Fixed a typo in the above (added word "be").

JD


-- 
Command Prompt, Inc.  http://the.postgres.company/
  +1-503-667-4564
PostgreSQL Centered full stack support, consulting and development.


--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make 
changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general



-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

[GENERAL] WIP: CoC V7

2016-01-15 Thread Joshua D. Drake 

tl;dr;

 * Cleaned up first paragraph, making it more succint
 * Reworded last bullet a bit


== PostgreSQL Community Code of Conduct (CoC) ==

This document provides community guidelines for a safe, respectful, 
productive, and collaborative place for any person who is willing to 
contribute to the PostgreSQL community. It applies to all "collaborative 
space", which is defined as community communications channels (such as 
mailing lists, IRC, submitted patches, commit comments, etc.).


* We are tolerant of people’s right to have opposing views.

* Participants must ensure that their language and actions are free
of personal attacks and disparaging personal remarks.

* When interpreting the words and actions of others, participants
should always assume good intentions.

* Participants who disrupt the collaborative space, or participate in a 
pattern of behaviour which could considered harassment will not be 
tolerated.


--
Command Prompt, Inc.  http://the.postgres.company/
 +1-503-667-4564
PostgreSQL Centered full stack support, consulting and development.


--
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] WIP: CoC V7

2016-01-15 Thread Joshua D. Drake 

On 01/15/2016 07:41 AM, Joshua D. Drake wrote:

tl;dr;

  * Cleaned up first paragraph, making it more succint
  * Reworded last bullet a bit


== PostgreSQL Community Code of Conduct (CoC) ==

This document provides community guidelines for a safe, respectful,
productive, and collaborative place for any person who is willing to
contribute to the PostgreSQL community. It applies to all "collaborative
space", which is defined as community communications channels (such as
mailing lists, IRC, submitted patches, commit comments, etc.).

* We are tolerant of people’s right to have opposing views.

* Participants must ensure that their language and actions are free
of personal attacks and disparaging personal remarks.

* When interpreting the words and actions of others, participants
should always assume good intentions.



* Participants who disrupt the collaborative space, or participate in a
pattern of behaviour which could be considered harassment will not be
tolerated.

Fixed a typo in the above (added word "be").

JD


--
Command Prompt, Inc.  http://the.postgres.company/
 +1-503-667-4564
PostgreSQL Centered full stack support, consulting and development.


--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

[GENERAL] Adding node to bdr group

2016-01-15 Thread Cj B 
Hi there, I want to add another node to my BDR group and was wondering what
the best practice is. My database is about 4gb. Current servers on west
coast and new server is on east coast.

Can I just do a bdr.bdr_group_join
?
Just want to confirm what the best practice is as I haven't seen anything
in the documentation about this.

Re: [GENERAL] Unable to build python extension with PGXS

2016-01-15 Thread Jim Nasby 

On 1/13/16 3:11 PM, Jim Nasby wrote:

On 1/12/16 10:04 PM, Jim Nasby wrote:

Attempting to build a python extension, I'm getting:

Undefined symbols for architecture x86_64:
   "_PyErr_Clear", referenced from:
   _PLyNdarray_FromDatum in pg_ndarray.o
   _PLyObject_To_ndarray in pg_ndarray.o


In case anyone runs into this in the future, my eventual solution was 
https://github.com/decibel/PandaPost/blob/master/Makefile

--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com


--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

[GENERAL] Re: [BUGS] about test_parser installation failure problem(PostgreSQL in 9.5.0)？

2016-01-15 Thread Michael Paquier 
On Sat, Jan 16, 2016 at 2:03 AM, Tom Lane  wrote:
> "=?utf-8?B?6Zas6Zas44Kk44G1?="  writes:
>>  test_parser install is ok (postgresql 9.2.4)
>> but at (postgresql 9.5.0) failure？
>
> Yes, we moved test_parser and some other only-useful-for-testing modules
> from contrib to src/test/modules, which means they won't get installed in
> standard installations.

Additional note: on Windows when code is compiled with MSVC, they are installed.
-- 
Michael


-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

[GENERAL] Re: [BDR] Best practice to automatically abort a DDL operation when one node is down

2016-01-15 Thread Sylvain MARECHAL 



I am using BDR with two nodes 1 and 2.
If I issue a DDL operation in node 1 when node 2 is down, for example:
  CREATE TABLE test (i int PRIMARY KEY); (1)

all other transactions fail with the following error:
  Database is locked against DDL operations

The problem is that the (1) DDL request will wait indefinitely, 
meaning all transactions will continue to fail until the DDL operation 
is manually aborted (for example, doing CTRL C in psql to abort the 
"CREATE TABLE").


What is the best practice to make sure the DDL operation will fail, 
possibly after a timeout, if one of the node is down? I could check 
the state of the node before issuing the DDL operation, but this 
solution is far from being perfect as the node may fail right after this.




Answering to myself, I guess no magic SQL command exists for this, I 
have to cancel the request with pg_cancel_backend() (in fact, that what 
the does says, I was guessing if something could detect this 
automatically and abort the request).


If using a blocking API, this means one should fork the task and monitor 
it to decide whether it should be canceled or not if it takes to much 
time (check if one of the node is down, then cancel the request and 
retry it later when the node will be up again).


--
Sylvain


--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general