[GENERAL] Issue with jdbc_fdw on Postgres 9.5

[pafiti]

I have recently installed Postgres 9.5 on CentOS 7.
I would like to connect this instance to an Hadoop cluster where data is
managed by Phoenix (over hBase).
My idea was to establish a link between Postgres and Phoenix thanks to
jdbc_fdw.

However, when I compiled the jdbc_fdw, it didn't put the things in the right
place.

I realized this when trying to create jdbc_fdw Extension.
Postgres will look for  "/usr/pgsql-9.5/share/extension/jdbc_fdw.control"
while the file has been copied into /usr/share/pgsql/extension.
With fixing this, I realized that this file contained
module_pathname=$libdir/jdbc_fdw.so while it had been installed in
$pkglibdir.
After fixing this, I still get an error when trying to create the extension
:

ERROR: invalid macro name in dynamic library path: $pkglibdir/jdbc_fdw
SQL state: 42602


I was wondering if jdbc_fdw was compatible with recent Postgres releases and
it there was another way to address my Phoenix database.

Thanks,
Patrick



--
View this message in context: 
http://postgresql.nabble.com/Issue-with-jdbc-fdw-on-Postgres-9-5-tp5884217.html
Sent from the PostgreSQL - general mailing list archive at Nabble.com.


-- 
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] request for comment re "contributor-covenant.org"

[Geoff Winkless]

Wow. And I was annoyed with myself that _I'd_ wasted so much time by
being drawn into this nonsense.

It appears that the only way to deal with the covenant and its
proponents is just to say "lalalalalala can't hear you" because they
will not listen to reason or take on board that any of what they
suggest isn't the One True Path; it's a religion by another name, and
you're trying to argue with zealots. Take it from me, it will be
seriously bad for your mental health to try to persuade them away from
it.

On 26 January 2016 at 00:48, Zenaan Harkness  wrote:
> Warning, some people may consider the following analysis to have one
> or two trigger words and or to be insensitive.
>
> DO NOT read it if you are emotionally sensitive or otherwise
> challenged in regards to robust communications and the rights of
> amateur humans to create social spaces of their choosing.
>
> In principle, the concept of a "contributor covenant" sounds sensible,
> but my version of such a covenant would clearly be quite different to
> the one at http://contributor-covenant.org and the below is a very
> rough second draft (after having run it past a few friends off list)
> attempt at a response to that website's front page. Such a "covenant"
> worthy of the name would need a lot more work which I have not done.
>
> Also, I feel that it is important that certain things so far unsaid
> regarding c-c.org, ought be raised for discussion, although my version
> of raising discussion is unfortunately most likely to be
> controversial, so in general, unless you wish to pick the eyes and
> distill what I am struggling to say, don't read the below as it will
> likely be too much work for you - if there's the slightest chance you
> might take offense, this email is not for you.
>
> 
> Since the contributor-covenant.org got referenced, and I seem to
> remember reading allegedly 1000's of "open source projects" have
> "adopted" it, and there appears to quite the campaign to "encourage"
> the PostgreSQL project to likewise adopt that particular agreement, I
> figured it was time to read it and see what all the fuss is about.
>
> Those who chaperone more than one "open source" project mailing lists
> may wish to bring themselves up to speed with this so-called
> "covenant" before the steamroller hits your group/ list/ community,
> since it seems inevitable at this point.
>
> The below is my second woeful attempt (the first being private off
> list) to bring some sanity to the "covenant" discussion. It needs your
> improvements.
>
> I have put ">>" to readily distinguish text coming from c-c.org
>
> Good luck,
> Zenaan
>
> 
> http://contributor-covenant.org/
>
>>> Contributor Covenant
>>> A Code of Conduct for Open Source Projects.
>
> Sounds reasonable.
>
>
>>> Open Source has always been a foundation of the Internet, and with the 
>>> advent
>>> of social open source networks this is more true than ever.
>
> Let's hope free libre and open source software - FLOSS, stays as the 
> foundation
> of the Internet!
>
> "social open source networks" - what?? Facebook social network??
>
> Use of new terminology, without explaining that terminology, and
> presuming it is known and well understood terminology, in a document
> you are pushing as a new and additional "social contract" which others
> are pressed upon to adopt and enforce, is IMHO passive aggressive.
>
>
>>> But free, libre, and open source projects suffer from a startling lack of
>>> diversity, with dramatically low participation by women, people of color, 
>>> and
>>> other marginalized populations.
>
> Those who have an interest in promoting, assisting, sponsoring and generally
> facilitating "the diversity" within this particular libre software
> project or mailing list,
> are welcome to do so and in general, ought be supported to the extent that 
> their
> actions and words are neither actively nor passively aggressive towards any
> member of this mailing list, and are actually supportive of the
> technical goals of
> this project.
>
>
>>> Part of this problem
>
> Lack of diversity may be viewed as a problem.
>
> Such a viewpoint is a personal, individual matter. Your personal, individual
> opinion on this matter may be discussed, but in general is off topic for this
> mailing list.
>
> Speaking or writing that "lack of diversity is a problem", and even moreso,
> building the presumption into the words of a so-called "social covenant", 
> where
> that presumption is almost hidden and "not up for debate", is a passive
> aggressive approach to communication with others who may or may not
> disagree with this position.
>
> Passive aggressive communication is not welcome on this mailing list.
>
>
>>> lies with the very structure of some projects:
>
> What is "the very structure of a project"? This phrase is too generic, and not
> explained, despite the next part of that sentence which follows below, which
> appears to pretend to answer (or define) the phrase - it does not.
>
> Phrases a

[GENERAL] Case and accent insensitive

[Max]

Is there a collation for case and accent insensitive filter? I just found the 
use of operators like ILIKE ou CITEXT module but I can't use ILIKE in the 
queries and the CITEXT is a field-by-field solution for the case insensitive 
part of the problem. I also found the unaccent text search dictionary that 
could help with the accent part.
In the MySQL world we have the database level collation latin1_swedish_ci where 
'maca' = 'Maçã' is true and no field level configuration is required.
This database is hosted in Amazon Cloud so I'm also limited by what I can do in 
this environment.

Re: [GENERAL] adding a bdr node using bcv backup

[(Daniel Stolf)]

Hi Craig, how are you?

Just as an update, I figured it out...

First, here's my setup:
Node 1 and Node 2 running postgresql-bdr94-bdr and bdr enabled.
Node 3 with the same setup, ready to receive the snapshot clone.

These were my steps:
1) pg_start_backup
2) take snapshot from Node 1
3) pg_stop_backup
(alternatively, one could bring a node down and take the snapshot, instead
of the start_backup/stop_backup procedure)
4) bring clone up on Node 3
5) no need for pg_resetxlog -s, otherwise you'll get error
'postgresql-bdr94-bdr'
6) bdr_init_copy
7) checking the logs, I see the error 'ERROR:  replication slot
"bdr_16385_6241964183952916534_1_16385__" already exists'. It's trying to
create the replication slot for Node 2, even though it's already there
8) pg_drop_replication_slot('bdr_16385_6241964183952916534_1_16385__')
9) bdr on Node 3 finally (re)creates the replication slot for Node 2 and
resumes its operations.

Make some tests on all nodes, delete some previous records, insert new
ones... All seems to be working... Except for that minor hickup on step 7,
all went fine. Maybe bdr could check if the replication slot is already
exists before trying to create it and move along if it's already there?

Thanks a lot!


On Fri, Jan 22, 2016 at 6:57 AM Craig Ringer  wrote:

> On 21 January 2016 at 20:46, (Daniel Stolf)  wrote:
>
>
>> So here's what I don't get:
>>
>> 1) if I have to create a new replication slots on node1 and 2 beforehand
>> using "pg_create_physical_replication_slot" , don't they need the if of
>> node3 on their name?
>>
>
> You need to create a logical replication slot with the 'bdr' plugin, since
> that's what BDR uses.
>
>
>> 2) If node3 has the same name and if as node1, won't that introduce a
>> conflic? Don't I need to clean that up before node3 can join the
>> replication group?
>>
>
> It will not have the same sysid.  bdr_init_copy resets it normally. If
> you're doing it manually you'd have to run pg_resetxlog with the option to
> reset the sysid, create the new slots with the new sysid, then make sure
> bdr_init_copy doesn't reset the sysid again it afterwards when it brings
> the new node up.
>
> Honestly I don't remember the exact steps that had to be performed before
> bdr_init_copy got support for automating the pg_basebackup step. That's the
> supported way to do it. I'm trying to prepare some conference presentations
> and a new pglogical release so I can't presently dig into it further for
> you; you may need to take a look at the bdr_init_copy sources and/or study
> how the node bringup works in more detail.
>
> I can see it being useful to add a new mode to bdr_init_copy where you
> tell it to generate a sysid and make new slots for that sysid; *then* you
> make a snapshot and restore it, then you run bdr_init_copy again to finish
> bringup, resetting the sysid to the new value and finishing setup. There's
> nothing like that now though.
>
> --
>  Craig Ringer   http://www.2ndQuadrant.com/
>  PostgreSQL Development, 24x7 Support, Training & Services
>

[GENERAL] prefix package availability for 9.5

[Hubbard, Matt R W]

I was hoping to be able to use the prefix module with postgresql 9.5.

However, I'm not finding it in the redhat 7 repo:
https://download.postgresql.org/pub/repos/yum/9.5/redhat/rhel-7-x86_64/

It is available for 9.4:
https://download.postgresql.org/pub/repos/yum/9.4/redhat/rhel-7-x86_64/

It is available for debian:
https://packages.debian.org/sid/postgresql-9.5-prefix


I'm afraid I've no idea how the build system for the modules works, I had a 
quick search and found buildfarm.postgresql.org, but this doesn't seem to cover 
modules.

Is there something that needs fixing somewhere to get prefix95 published for 
rhel-7-x86_64? How would one find out?

Many thanks,
Matt

Re: [GENERAL] Tutorial on How to Compile PostgreSQL 9.5 for Windows 64bit

[Edson F. Lidorio]

On 25-01-2016 16:46, Igal @ Lucee.org wrote:

Hi Everybody,

I have posted a video tutorial on How to Compile PostgreSQL 9.5 for 
Windows 64bit

https://www.youtube.com/watch?v=-BJmuZT5IPE

It was quite difficult for me to figure it out, so hopefully it will 
make life easier for

the next guy (or gal).

--

Igal Sapir
Lucee Core Developer
Lucee.org 


Hello,
Excellent Tutorial,
How to compile the master version 9.6 Dev, for Linux?

Re: [GENERAL] Tutorial on How to Compile PostgreSQL 9.5 for Windows 64bit

[Shulgin, Oleksandr]

On Tue, Jan 26, 2016 at 4:21 PM, Edson F. Lidorio 
wrote:

>
>
> On 25-01-2016 16:46, Igal @ Lucee.org wrote:
>
> Hi Everybody,
>
> I have posted a video tutorial on How to Compile PostgreSQL 9.5 for
> Windows 64bit
> https://www.youtube.com/watch?v=-BJmuZT5IPE
>
> It was quite difficult for me to figure it out, so hopefully it will make
> life easier for
> the next guy (or gal).
>
> --
>
> Igal Sapir
> Lucee Core Developer
> Lucee.org 
>
> Hello,
> Excellent Tutorial,
> How to compile the master version 9.6 Dev, for Linux?
>

Basically, as outlined on this page:
https://wiki.postgresql.org/wiki/Compile_and_Install_from_source_code

I also find "apt-get build-dep postgresql-common" command particularly
useful.

-- 
Alex

Re: [GENERAL] Tutorial on How to Compile PostgreSQL 9.5 for Windows 64bit

[John R Pierce]

On 1/26/2016 7:21 AM, Edson F. Lidorio wrote:

How to compile the master version 9.6 Dev, for Linux?



do note, 9.6 is still a early beta, and is probably 6 months from 
feature complete and a year+ from release.




--
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] CoC [Final v2]

[Jan Danielsson]

On 24/01/16 18:30, Joshua D. Drake wrote:
[---]
> This is something that I brought up in protest because I believe that it
> is crucial to the growth of this community.

   Do you have any evidence to support this belief?  (Without referring
to an anonymous invisible mass, a single case or unverifiable anecdotal
evidence).

   Without any data/evidence either way I'd wager that the
implementation of a CoC will have exactly zero effect on developers
coming to or going from the project.  If gaining developers is your
motivator for pushing through a CoC, I for one believe it's a waste of
time and energy.

   I don't buy the idea that there's a huge cache of talent waiting in
the dark for open source projects to suddenly implement a CoC, at which
point they'll jump out and suddenly start contributing code.  Though
whatever anecdotal evidence I could produce to support that claim would
be as worthless as anyone else's, so:

   Surely considering the huge number of projects which have adopted
various forms of CoC's over the past months/years there are good numbers
to show if they have a positive effect on contributions?

   I'd be happy to be proven wrong, but I suspect you'll find zero
correlation between implementation of CoC's and number of contributions
and/or contributors.


   A wider question to the other participants in this discussion:  Is it
generally an accepted view that the growth of the community (in some
sense) is contingent on the implementation of a CoC?

   /Jan



-- 
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] Case and accent insensitive

[rob stone]

On Tue, 2016-01-26 at 11:06 +, Max wrote:
> Is there a collation for case and accent insensitive filter? I just
> found the use of operators like ILIKE ou CITEXT module but I can't
> use ILIKE in the queries and the CITEXT is a field-by-field solution
> for the case insensitive part of the problem. I also found
> the unaccent text search dictionary that could help with the accent
> part.
> 
> In the MySQL world we have the database level
> collation latin1_swedish_ci where 'maca' = 'Maçã' is true and no
> field level configuration is required.
> 
> This database is hosted in Amazon Cloud so I'm also limited by what I
> can do in this environment.


Have you considered storing the text in its HTML equivalent?

So "maçã" becomes "apple" in Portuguese.

You'd have to convert your query parameters before running the select.

My tuppence worth.

HTH
Robert


-- 
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] CoC [Final v2]

[Joshua D. Drake]

On 01/26/2016 09:03 AM, Jan Danielsson wrote:

On 24/01/16 18:30, Joshua D. Drake wrote:


Hello,

This thread is deprecated. The CoC Final Draft has been submitted to 
-core for final modification, acceptance or decline.


Sincerely,

Joshua D. Drake

--
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] Can PostgreSQL use multi-column index for FK constraint validation?

[Dane Foster]

Hello,

If I have a primary key index of the form:
(col1, col2, col3)
and a foreign key constraint of the form:
FOREIGN KEY (col1, col2) REFERENCES foo
 ON DELETE CASCADE ON UPDATE CASCADE
should I create a separate index (col1, col2) or is PostgreSQL capable of
using the primary key's index?

Thanks,

Dane

Re: [GENERAL] request for comment re "contributor-covenant.org"

[Josh Berkus]

Zenaan,

> I simply wrote in first person with the intention to catalyse thought
> about what could and or should and or should not be in such a
> "covenant". In no way was the email any statement of authority and I
> had hoped to make that clear, evidently not.

It wasn't.  And while longterm community members know that you have no
moderation authority, there are a lot of newcomers on this list.

> On the topic, I feel it will take a few years yet for "the libre
> software community" to come to anything approaching a consensus
> regarding "community covenant"; just my opinion of course.

Personally, I doubt the entire FLOSS universe would *ever* come to an
agreement on anything, except maybe that code ought to be OSS-licensed.

-- 
Josh Berkus
Red Hat OSAS
(opinions are my own)


-- 
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] Can PostgreSQL use multi-column index for FK constraint validation?

[Josh Berkus]

On 01/26/2016 11:38 AM, Dane Foster wrote:
> Hello,
> 
> If I have a primary key index of the form:
> (col1, col2, col3)
> and a foreign key constraint of the form:
> FOREIGN KEY (col1, col2) REFERENCES foo
>  ON DELETE CASCADE ON UPDATE CASCADE
> should I create a separate index (col1, col2) or is PostgreSQL capable
> of using the primary key's index?

You are not required to create one.

foo(col1, col2) needs a unique index.  There need not be any specific
index on (col1, col2) in the referencing table.  Whether you want one
for performance depends on how selective (col1, col2) is without col3,
and how large the table is.

-- 
Josh Berkus
Red Hat OSAS
(opinions are my own)


-- 
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] CoC [Final v2]

[FarjadFarid(ChkNet)]

Well done Joshua D. Drake and thank you for the hard work putting up with so 
many comments. 

Hope it is all worth it. 

-Original Message-
From: pgsql-general-ow...@postgresql.org 
[mailto:pgsql-general-ow...@postgresql.org] On Behalf Of Joshua D. Drake
Sent: 26 January 2016 19:01
To: Jan Danielsson; pgsql-general@postgresql.org
Subject: Re: [GENERAL] CoC [Final v2]

On 01/26/2016 09:03 AM, Jan Danielsson wrote:
> On 24/01/16 18:30, Joshua D. Drake wrote:

Hello,

This thread is deprecated. The CoC Final Draft has been submitted to -core for 
final modification, acceptance or decline.

Sincerely,

Joshua D. Drake

-- 
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

Re: [GENERAL] Can PostgreSQL use multi-column index for FK constraint validation?

[Dane Foster]

On Tue, Jan 26, 2016 at 3:15 PM, Josh Berkus  wrote:

> On 01/26/2016 11:38 AM, Dane Foster wrote:
> > Hello,
> >
> > If I have a primary key index of the form:
> > (col1, col2, col3)
> > and a foreign key constraint of the form:
> > FOREIGN KEY (col1, col2) REFERENCES foo
> >  ON DELETE CASCADE ON UPDATE CASCADE
> > should I create a separate index (col1, col2) or is PostgreSQL capable
> > of using the primary key's index?
>
> You are not required to create one.
>
> foo(col1, col2) needs a unique index.  There need not be any specific
> index on (col1, col2) in the referencing table.  Whether you want one
> for performance depends on how selective (col1, col2) is without col3,
> and how large the table is.
>
> --
> Josh Berkus
> Red Hat OSAS
> (opinions are my own)
>
>
> --
> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general
>
​
My example is modeling an order details table and the answer to the
question of selectivity is it depends. For some of our clients it is highly
selective because customers generally order a single item at a time. For
others it's multi-modal because it starts out w/ their customers ordering
only a single item but over time customer behavior changes and there is
this mix of single and multi item orders. Additionally my use case for
PostgreSQL is the VPS use case where each client has their own schema so
I'd prefer not to have to deal w/ per client index building and
maintenance. So is there a rule of thumb design wise for variable
selectivity as I've described?



Dane
​

Re: [GENERAL] Can PostgreSQL use multi-column index for FK constraint validation?

[Tom Lane]

Dane Foster  writes:
> My example is modeling an order details table and the answer to the
> question of selectivity is it depends. For some of our clients it is highly
> selective because customers generally order a single item at a time. For
> others it's multi-modal because it starts out w/ their customers ordering
> only a single item but over time customer behavior changes and there is
> this mix of single and multi item orders. Additionally my use case for
> PostgreSQL is the VPS use case where each client has their own schema so
> I'd prefer not to have to deal w/ per client index building and
> maintenance. So is there a rule of thumb design wise for variable
> selectivity as I've described?

See
http://www.postgresql.org/docs/9.4/static/indexes.html
particularly sections 11.3 and 11.5.

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] Can PostgreSQL use multi-column index for FK constraint validation?

[Josh Berkus]

On 01/26/2016 12:47 PM, Dane Foster wrote:
> My example is modeling an order details table and the answer to the
> question of selectivity is it depends. For some of our clients it is
> highly selective because customers generally order a single item at a
> time. For others it's multi-modal because it starts out w/ their
> customers ordering only a single item but over time customer behavior
> changes and there is this mix of single and multi item orders.
> Additionally my use case for PostgreSQL is the VPS use case where each
> client has their own schema so I'd prefer not to have to deal w/ per
> client index building and maintenance. So is there a rule of thumb
> design wise for variable selectivity as I've described?

Well, my general perspective is that if the table has millions of rows
(or more), and there are 100's (or more) of col3 items for each
col1/col2 combo, then I'd *probably* add a specific FK index.

Given the "I don't know" you have above, I generally wouldn't add one,
and then look at response times on updates/deletes to the orders table
to see if there's a performance issue.

-- 
Josh Berkus
Red Hat OSAS
(opinions are my own)


-- 
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] Can PostgreSQL use multi-column index for FK constraint validation?

[Igor Neyman]

From: pgsql-general-ow...@postgresql.org 
[mailto:pgsql-general-ow...@postgresql.org] On Behalf Of Dane Foster
Sent: Tuesday, January 26, 2016 2:39 PM
To: pgsql-general 
Subject: [GENERAL] Can PostgreSQL use multi-column index for FK constraint 
validation?

Hello,
If I have a primary key index of the form:
(col1, col2, col3)
and a foreign key constraint of the form:
FOREIGN KEY (col1, col2) REFERENCES foo
 ON DELETE CASCADE ON UPDATE CASCADE
should I create a separate index (col1, col2) or is PostgreSQL capable of using 
the primary key's index?
Thanks,

Dane

Columns in proposed index on FK (col1, col2) are in the same order (and in the 
beginning) of PK index.
So, no need for additional index (col1, col2).

Regards,
Igor Neyman

[GENERAL] Does pglogical support PG 9.4.5?

[leo]

Hi all, 

I am test pglogical on PG 9.4.5, but I am not successfully even if I
install the latest version "postgresql94-pglogical-1.0.1-2". 
Is there any one running pglogical on PG 9.4.5 successfully? 
I describe my operation step, please help me to trouble shooting? 

provider node: 10.10.10.11 
subscriber node: 10.10.10.103 
  
Config pg_hba.conf on provider node: 

hostall postgres0.0.0.0/0 trust 
hostreplication postgres10.10.10.103/0  trust   
  
Config pg_hba.conf on subscriber node: 
  
hostall postgres0.0.0.0/0 trust 
hostreplication postgres10.10.10.11/0  trust   

Config the postgres.conf according to README 


1. Create subscribe node: 
Provider: 10.10.10.11 
 SELECT pglogical.create_node(node_name := 'subscriber_test_3',dsn :=
'hostaddr= 10.10.10.103 port=5509 dbname=testdb user=postgres'); 
 create_node 
- 
  2393536845 

2. Create replication ser 
 select pglogical.create_replication_set('replicate_gis_data', true, true,
true, true); 
 create_replication_set 
 
 2904604760 

3. Add table into replication set 

select
pglogical.replication_set_add_table('replicate_gis_data','test_table',
true); 


===Executing on subscriber node 
Enable the network connection on: 
  enbale network connection and replication connection without password 


1. Create provider: 
SELECT pglogical.create_node(node_name := 'provider_test_2',dsn :=
'hostaddr= 10.10.10.11 port=5508 dbname=testdb user=postgres'); 
create_node 
- 
  3082486013 


2. Create subscription to provider noede, executing on subscribe node 

select pglogical.create_subscription('replicate_gis_data_from_11',
'hostaddr= 10.10.10.11 port=5508 dbname=testdb
user=postgres',E'{"replicate_gis_data"}'); 



Error Message on subscriber node 
=== 

< 2016-01-12 19:45:41.396 UTC >DEBUG:  shmem_exit(1): 2 before_shmem_exit
callbacks to make 
< 2016-01-12 19:45:41.396 UTC >DEBUG:  shmem_exit(1): 6 on_shmem_exit
callbacks to make 
< 2016-01-12 19:45:41.396 UTC >DEBUG:  proc_exit(1): 2 callbacks to make 
< 2016-01-12 19:45:41.396 UTC >DEBUG:  exit(1) 
< 2016-01-12 19:45:41.396 UTC >DEBUG:  shmem_exit(-1): 0 before_shmem_exit
callbacks to make 
< 2016-01-12 19:45:41.396 UTC >DEBUG:  shmem_exit(-1): 0 on_shmem_exit
callbacks to make 
< 2016-01-12 19:45:41.396 UTC >DEBUG:  proc_exit(-1): 0 callbacks to make 
< 2016-01-12 19:45:41.397 UTC >DEBUG:  reaping dead processes 
< 2016-01-12 19:45:41.397 UTC >LOG:  worker process: pglogical apply
26429:2377587811 (PID 967) exited with exit code 1 
< 2016-01-12 19:45:41.397 UTC >DEBUG:  StartTransaction 
< 2016-01-12 19:45:41.397 UTC >LOG:  unregistering background worker
"pglogical apply 26429:2377587811" 
< 2016-01-12 19:45:41.397 UTC >DEBUG:  name: unnamed; blockState:  
DEFAULT; state: INPROGR, xid/subid/cid: 0/1/0, nestlvl: 1, children: 
< 2016-01-12 19:45:41.397 UTC >LOG:  registering background worker
"pglogical apply 26429:2377587811" 
< 2016-01-12 19:45:41.397 UTC >LOG:  starting background worker process
"pglogical apply 26429:2377587811" 
< 2016-01-12 19:45:41.397 UTC >DEBUG:  CommitTransaction 
< 2016-01-12 19:45:41.397 UTC >DEBUG:  name: unnamed; blockState:  
STARTED; state: INPROGR, xid/subid/cid: 0/1/0, nestlvl: 1, children: 
< 2016-01-12 19:45:41.397 UTC >DEBUG:  find_in_dynamic_libpath: trying
"/usr/pgsql-9.4/lib/pglogical" 
< 2016-01-12 19:45:41.397 UTC >DEBUG:  find_in_dynamic_libpath: trying
"/usr/pgsql-9.4/lib/pglogical.so" 
< 2016-01-12 19:45:41.397 UTC >DEBUG:  InitPostgres 
< 2016-01-12 19:45:41.397 UTC >DEBUG:  my backend ID is 8 
< 2016-01-12 19:45:41.397 UTC >DEBUG:  StartTransaction 
< 2016-01-12 19:45:41.397 UTC >DEBUG:  name: unnamed; blockState:  
DEFAULT; state: INPROGR, xid/subid/cid: 0/1/0, nestlvl: 1, children: 
< 2016-01-12 19:45:41.397 UTC >DEBUG:  CommitTransaction 
< 2016-01-12 19:45:41.397 UTC >DEBUG:  name: unnamed; blockState:  
STARTED; state: INPROGR, xid/subid/cid: 0/1/0, nestlvl: 1, children: 
< 2016-01-12 19:45:41.397 UTC >DEBUG:  StartTransaction 
< 2016-01-12 19:45:41.398 UTC >DEBUG:  name: unnamed; blockState:  
DEFAULT; state: INPROGR, xid/subid/cid: 0/1/0, nestlvl: 1, children: 
< 2016-01-12 19:45:41.398 UTC >DEBUG:  CommitTransaction 
< 2016-01-12 19:45:41.398 UTC >DEBUG:  name: unnamed; blockState:  
STARTED; state: INPROGR, xid/subid/cid: 0/1/0, nestlvl: 1, children: 
< 2016-01-12 19:45:41.398 UTC >DEBUG:  StartTransaction 
< 2016-01-12 19:45:41.398 UTC >DEBUG:  name: unnamed; blockState:  
DEFAULT; state: INPROGR, xid/subid/cid: 0/1/0, nestlvl: 1, children: 
< 2016-01-12 19:45:41.398 UTC >DEBUG:  CommitTransaction 
< 2016-01-12 19:45:41.398 UTC >DEBUG:  name: unnamed; blockState:  
STARTED; state: INPROGR, xid/subid/cid: 0/1/0, nestlvl: 1, children: 
< 2016-01-12 19:45:41.398 UTC >ERROR:  subscriber replicate_gis_data_from

[GENERAL] Code of Conduct plan

[Josh Berkus]

Community members:

A number of people have contacted the Core Team about taking action
regarding a Code of Conduct (CoC) for the project. After some
discussion, the plan we have come up with is below.

**Please do not reply-all to this email, as we do not wish to generate
additional list traffic regarding CoCs**

1. The Core Team will appoint an exploration committee which will look
at various proposals (including the one drafted on pgsql-general) for
CoCs and discuss them. This committee will include both major community
members and less central folks who have hands-on experience with CoCs
and community management issues.  If you know of PostgreSQL community
members who have relevant experience, please nominate them by emailing
the core team: pgsql-c...@postgresql.org.

2. We will also hire a professional consultant to advise the committee
on CoC development, adoption, training, and enforcement.  Again, if
community members have a consultant to recommend, please email the core
team.

3. This committee will post a draft CoC or possibly a selection of draft
CoCs by or before late April for community comment.  Likely the
committee will be publishing drafts more frequently, but that will be up
to them to work out.

4. At the pgCon Community Unconference, and again at pgconf.EU, we will
have sessions where people can discuss and provide feedback about
proposed (or adopted) CoCs.  Possibly we will have CoC-related trainings
as well.

5. Once a draft is agreed upon, it will be circulated to our various
sub-communities for comment.

6. A "final" CoC will be endorsed by the committee and the Core Team
shortly after pgConf.EU, unless there is sufficently strong consensus to
adopt one before then.

Yes, we realize this is a long timeline.  The PostgreSQL Project has
never been about implementing things in a hurry; our practice has always
been to take all of the time required to develop the right feature the
right way.  Adopting a CoC is no different; if anything, we need to take
*more* time in order to get input from community members who do not
speak up frequently or assertively.

In the meantime, our policy remains: if you have experienced harassment
or feel that you are being treated unfairly by other project members,
email the Core Team and we will investigate your complaint and take
appropriate action.

Also, we want to thank Josh Drake for raising the CoC issue and getting
it off the TODO list and into process, and devising an initial "seed"
CoC.  Such things are all too easy to keep postponing.

Again, Please DO NOT comment on this plan on-list; one of the pieces of
feedback we have received loud and clear is that many community members
are unhappy with the amount of list traffic devoted to the subject of
CoCs.  As such, if you have comments on the plan above, please email the
core team instead of replying on-list, or wait for the committee and
address comments to them.

--Josh Berkus
  PostgreSQL Core Team


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