Re: [GENERAL] pglogical bidirectional replication of sequences

[Peter J. Holzer]

On 2017-09-01 10:29:51 +0200, Peter J. Holzer wrote:
> pglogical supports replication of sequences, and although the way it
> does this suggests that it can't really work in both directions
> (actually I'm sceptical that it works reliably in one direction), of
> course I had to try it.
> 
> So I created a sequence on both nodes and called
> select pglogical.replication_set_add_sequence('default', 'test_sequence');
> on both nodes.
> 
> The result was ... interesting.
> 
> First I got the same sequence (1, 2, 3, 4, 5) on both nodes.
> 
> After a few seconds the replication kicked in, and then I got the same
> value (1005) on both nodes most of the time, with a few variants (2005,
> 3005) thrown in.
> 
> In a word, the sequence was completely unusable.

[...some failed attempts to recover...]

> So, is there a way to recover from this situation without drastic
> measures like nuking the whole database.

To answer my own question:

delete from pglogical.queue where message_type='S';
on both nodes seems to have the desired effect.
A vacuum full pglogical.queue afterwards is a good idea to get the
bloated table back to a reasonable size.

hp



-- 
   _  | Peter J. Holzer| we build much bigger, better disasters now
|_|_) || because we have much more sophisticated
| |   | h...@hjp.at | management tools.
__/   | http://www.hjp.at/ | -- Ross Anderson 


signature.asc
Description: Digital signature

Re: [GENERAL] pglogical bidirectional replication of sequences

[Peter J. Holzer]

On 2017-09-01 09:57:52 -0600, Rob Sargent wrote:
> On 09/01/2017 02:29 AM, Peter J. Holzer wrote:
> >TLDR: Don't.
> >
> >I'm currently conducting tests which should eventually lead to a 2 node
> >cluster with working bidirectional logical replication.
> >
> >(Postgresql 9.6.4-1.pgdg90+1, pglogical 2.0.1-1.jessie+1 on Debian 9
> >(Stretch))
> >
> >pglogical supports replication of sequences, and although the way it
> >does this suggests that it can't really work in both directions
> >(actually I'm sceptical that it works reliably in one direction), of
> >course I had to try it.
> >
[and it blew up]

> I trust you mean don't use sequences

I trust you don't mean what I understood ;-).

Seriously:

Sequences in general are fine and very useful. I think they should be
used where appropriate.

Sequences and logical replication don't mix well. That still doesn't
mean that you can't use sequences, you just have to be careful how you
use them. 

Since replicating sequence state doesn't really work, I think it is best
to use independent sequences on each node and just configure them in a
way that they can not produce the same values. A naive approach would be
to use MINVALUE/MAXVALUE/START WITH to ensure non-overlapping ranges. A
somewhat more elegant approach is to increment by $n$ (the number of
nodes in the cluster) and use different start values (I got that idea
from
http://thedumbtechguy.blogspot.co.at/2017/04/demystifying-pglogical-tutorial.html).
 

There are other ways to get unique ids: A uuid should work pretty well
in most cases, and in some even a random 64 bit int might be enough.

hp

-- 
   _  | Peter J. Holzer| we build much bigger, better disasters now
|_|_) || because we have much more sophisticated
| |   | h...@hjp.at | management tools.
__/   | http://www.hjp.at/ | -- Ross Anderson 


signature.asc
Description: Digital signature

Re: [GENERAL] pglogical bidirectional replication of sequences

[Rob Sargent]

On 09/01/2017 02:29 AM, Peter J. Holzer wrote:

TLDR: Don't.

I'm currently conducting tests which should eventually lead to a 2 node
cluster with working bidirectional logical replication.

(Postgresql 9.6.4-1.pgdg90+1, pglogical 2.0.1-1.jessie+1 on Debian 9
(Stretch))

pglogical supports replication of sequences, and although the way it
does this suggests that it can't really work in both directions
(actually I'm sceptical that it works reliably in one direction), of
course I had to try it.

So I created a sequence on both nodes and called
select pglogical.replication_set_add_sequence('default', 'test_sequence');
on both nodes.

The result was ... interesting.

First I got the same sequence (1, 2, 3, 4, 5) on both nodes.

After a few seconds the replication kicked in, and then I got the same
value (1005) on both nodes most of the time, with a few variants (2005,
3005) thrown in.

In a word, the sequence was completely unusable.

Experiment completed, so I removed the sequence from the replication
set:

select pglogical.replication_set_remove_sequence('default', 'test_sequence');
on both nodes.

But the behaviour of the sequence doesn't change. It still returns 1005
most of the time, and sometimes 2005 or 3005. This is true even after
restarting both nodes.

Plus, I can't drop the sequence any more (as the user who created the
sequence):

wds=> drop sequence public.test_sequence ;
ERROR:  permission denied for schema pglogical

So, clearly, pglogical is still managing that sequence.

If I drop the sequence as postgres and then recreate it, it works
normally for some time (also the sequence on the other node now works
normally), but after some time, the replication kicks in again and the
sequence is stuck again at 1005.

So, is there a way to recover from this situation without drastic
measures like nuking the whole database.

 hp

I trust you mean don't use sequences



--
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] pglogical sync

[armand pirvu]

I see says the blind man

Looked in the code

and correct the syntax and ran on subscriber

all good

> On Aug 10, 2017, at 12:29 PM, armand pirvu  wrote:
> 
> Hi folks
> 
> A question about pglogical sync
> 
> I have a setup with a schema named myschema.
> All works well but looking at sync
> 
> pglogical.alter_subscription_resynchronize_table(subscription_name name, 
> relation regclass) 
> Resynchronize one existing table. WARNING: This function will truncate the 
> table first.
> Parameters:
> subscription_name - name of the existing subscription
> relation - name of existing table, optionally qualified
> 
> How exactly to you run this ? What am I missing ?
> 
> 
> testrep=# select 
> pglogical.alter_subscription_resynchronize_table(subscription_name := 
> 'mysubscription', 'myschema.tbl1');
> ERROR:  positional argument cannot follow named argument
> LINE 1: ...nize_table(subscription_name := 'mysubscription', 'myschema
>  ^
> testrep=# select 
> pglogical.alter_subscription_resynchronize_table(subscription_name := 
> 'mysubscription', 'myschema.tbl1'::regclass);
> ERROR:  positional argument cannot follow named argument
> LINE 1: ...nize_table(subscription_name := 'mysubscription', 'myschema
>
> 
> 
> 
> Thanks for help
> 
> Armand
> 
> 
> 

Re: [GENERAL] pglogical repo

[armand pirvu]

Updated since last time I installed it

Okay

Will go move from 1.0.2 to 1.0.3 to stay up to date



Thks



> On Aug 10, 2017, at 1:21 PM, John R Pierce  wrote:
> 
> On 8/10/2017 10:30 AM, armand pirvu wrote:
>> Looking at the installatoion steps and the yum repositories
>> 
>> sudo yum 
>> installhttp://packages.2ndquadrant.com/pglogical/yum-repo-rpms/pglogical-rhel-1.0-2.noarch.rpm
>> 
>> [   ] pglogical-rhel-1.0-1.noarch.rpm
>> [   ] pglogical-rhel-1.0-2.noarch.rpm
>> [   ] pglogical-rhel-1.0-3.noarch.rpm
>> 
>> 
>> 1.0-3 is for Postgres 9.6 ? Or can it be used on 9.5 as well ? I am on 9.5
> 
> 
> That is clearly answered here, 
> https://www.2ndquadrant.com/en/resources/pglogical/pglogical-installation-instructions/
> 
> 
> -- 
> 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



-- 
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] pglogical repo

[John R Pierce]

On 8/10/2017 10:30 AM, armand pirvu wrote:

Looking at the installatoion steps and the yum repositories

sudo yum 
installhttp://packages.2ndquadrant.com/pglogical/yum-repo-rpms/pglogical-rhel-1.0-2.noarch.rpm

[   ] pglogical-rhel-1.0-1.noarch.rpm
[   ] pglogical-rhel-1.0-2.noarch.rpm
[   ] pglogical-rhel-1.0-3.noarch.rpm


1.0-3 is for Postgres 9.6 ? Or can it be used on 9.5 as well ? I am on 9.5



That is clearly answered here, 
https://www.2ndquadrant.com/en/resources/pglogical/pglogical-installation-instructions/



--
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] pglogical vs. built-in logical replication in pg-10

[Achilleas Mantzios]

On 22/06/2017 20:30, Andres Freund wrote:

On 2017-06-22 18:10:40 +0300, Achilleas Mantzios wrote:

Once again having pg_largeobject as a system-catalog prevents LOs
from working smoothly. Neither replication nor having LOs on a
different tablespace (by moving pg_largeobject) works.

I think logical decoding was designed for supporting DML SQL commands
(i.e. a finite set of commands) and not specific functions (lo_*)
which by nature can be arbitrary, infinite and version specific.

That's not really the reason. The first reason its currently unsupported
is that LOs are stored in a system catalog, and currently all system
catalogs are excluded from the change stream.  The second problem is how
exactly to represent the changes - we can't represent it as the whole LO
being changed, as that'd increase the volume of WAL and replicated
writes dramatically.  Thus we need to invent an API that can represent
creation, deletion, and writes to arbitrary offsets, for output plugins.


Thanx for the insight.




I wish PG in some future version will address these quirks so one can operate 
on LOs more smoothly.

You're welcome to help...


Greetings,

Andres Freund




--
Achilleas Mantzios
IT DEV Lead
IT DEPT
Dynacom Tankers Mgmt



--
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] pglogical vs. built-in logical replication in pg-10

[Andreas Joseph Krogh]

På torsdag 22. juni 2017 kl. 17:10:40, skrev Achilleas Mantzios <
ach...@matrix.gatewaynet.com >:
[snip]
What's so better in LO's VS bytea? You do a lot updates on the binary data, 
changing only parts of it?
 
BYTEA really sucks when dealing with large objects and streaming to clients 
(JDBC). The only solution (I've found) which doesn't explode in memory-usage is 
using LOs (OIDs). Note that we're dealing with multi-gigabytes objects, which 
need to be "transactional safe" (hence stored in the DB).
 
-- Andreas Joseph Krogh
CTO / Partner - Visena AS
Mobile: +47 909 56 963
andr...@visena.com 
www.visena.com 
 


 

Re: [GENERAL] pglogical vs. built-in logical replication in pg-10

[Andreas Joseph Krogh]

På torsdag 22. juni 2017 kl. 19:30:49, skrev Andres Freund >:
On 2017-06-22 18:10:40 +0300, Achilleas Mantzios wrote:
 > > Once again having pg_largeobject as a system-catalog prevents LOs
 > > from working smoothly. Neither replication nor having LOs on a
 > > different tablespace (by moving pg_largeobject) works.

 > I think logical decoding was designed for supporting DML SQL commands
 > (i.e. a finite set of commands) and not specific functions (lo_*)
 > which by nature can be arbitrary, infinite and version specific.

 That's not really the reason. The first reason its currently unsupported
 is that LOs are stored in a system catalog, and currently all system
 catalogs are excluded from the change stream.  The second problem is how
 exactly to represent the changes - we can't represent it as the whole LO
 being changed, as that'd increase the volume of WAL and replicated
 writes dramatically.  Thus we need to invent an API that can represent
 creation, deletion, and writes to arbitrary offsets, for output plugins.
 
pg_largeobject being a system catalog is the cause of much pain as I've found 
out. It also prevents moving it to a separate tablespace and maintaining 
pg_upgrade compatibility.
 
The first initiative would (possibly) be coming up with a new model for 
storing LOs, not involving system-catalogs. But, pg_largeobject doesn't seem 
all that magic and appears to contain "logical-decoding compatible" 
column-types:
 
\d pg_largeobject 
  Table "pg_catalog.pg_largeobject"
 ┌┬─┬───┬──┬─┐
 │ Column │  Type   │ Collation │ Nullable │ Default │
 ├┼─┼───┼──┼─┤
 │ loid   │ oid │   │ not null │ │
 │ pageno │ integer │   │ not null │ │
 │ data   │ bytea   │   │ not null │ │
 └┴─┴───┴──┴─┘

 If this was a regular table there would be nothing preventing it from being 
replicated successfully using logical decoding, correct?
 
 
> > I wish PG in some future version will address these quirks so one can 
operate on LOs more smoothly.

 You're welcome to help...
 
Every time issues arise regarding LOs there seems to be little interest to 
improve matters, and if it doesn't itch
 
-- Andreas Joseph Krogh
CTO / Partner - Visena AS
Mobile: +47 909 56 963
andr...@visena.com 
www.visena.com 
 


 

Re: [GENERAL] pglogical vs. built-in logical replication in pg-10

[Andres Freund]

On 2017-06-22 18:10:40 +0300, Achilleas Mantzios wrote:
> > Once again having pg_largeobject as a system-catalog prevents LOs
> > from working smoothly. Neither replication nor having LOs on a
> > different tablespace (by moving pg_largeobject) works.

> I think logical decoding was designed for supporting DML SQL commands
> (i.e. a finite set of commands) and not specific functions (lo_*)
> which by nature can be arbitrary, infinite and version specific.

That's not really the reason. The first reason its currently unsupported
is that LOs are stored in a system catalog, and currently all system
catalogs are excluded from the change stream.  The second problem is how
exactly to represent the changes - we can't represent it as the whole LO
being changed, as that'd increase the volume of WAL and replicated
writes dramatically.  Thus we need to invent an API that can represent
creation, deletion, and writes to arbitrary offsets, for output plugins.


> > I wish PG in some future version will address these quirks so one can 
> > operate on LOs more smoothly.

You're welcome to help...


Greetings,

Andres Freund


-- 
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] pglogical vs. built-in logical replication in pg-10

[Andres Freund]

On 2017-06-22 12:43:02 +0300, Achilleas Mantzios wrote:
> On 22/06/2017 11:21, Andreas Joseph Krogh wrote:
> > Hi.
> > 1. Why should one prefer built-in logical replication in pg-10 to 
> > pglogical, does it do anything pglogical doesn't?
> > It seems pglogical is more feature-rich...
> > 2. As I understand built-in logical replication in pg-10 doesn't support
> > large-objects, which we use a lot. Does pglogical replicate large
> > objects? I cannot find any notes about large-objects under "Limitations
> > and Restrictions":
> > https://www.2ndquadrant.com/en/resources/pglogical/pglogical-docs/

> You may do a simple test, create a table with a largeobject and try to read
> the logical stream, if it cannot represent the lo_import, lo_open, lowrite,
> lo_close (and I 'd bet they can't be encoded) then neither pglogical (being
> based on the same logical decoding technology) will support them.

There's nothing fundamental preventing us supporting large objects , but
indeed logical decoding at the moment doesn't support it.  The technical
bits of extracting changes should actually be easy, it's a bit more
difficult to decide how to represent it to output plugins...

Greetings,

Andres Freund


-- 
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] pglogical vs. built-in logical replication in pg-10

[Peter Eisentraut]

On 6/22/17 04:21, Andreas Joseph Krogh wrote:
> 1. Why should one prefer built-in logical replication in pg-10 to
> pglogical, does it do anything pglogical doesn't?
> It seems pglogical is more feature-rich...

You are right that pglogical has more functionality.  Much of that
functionality can be expected to trickle into core eventually.

One advantage of the in-core feature is that the initial table
synchronization can be parallelized, which can make the initial setup
faster and more robust.  pglogical will probably support that too at
some point once PG10 is out.

-- 
Peter Eisentraut  http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, 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] pglogical vs. built-in logical replication in pg-10

[Achilleas Mantzios]

On 22/06/2017 17:46, Andreas Joseph Krogh wrote:

På torsdag 22. juni 2017 kl. 15:25:20, skrev Achilleas Mantzios 
>:

On 22/06/2017 13:38, Andreas Joseph Krogh wrote:

På torsdag 22. juni 2017 kl. 11:43:02, skrev Achilleas Mantzios 
>:

On 22/06/2017 11:21, Andreas Joseph Krogh wrote:

Hi.
1. Why should one prefer built-in logical replication in pg-10 to 
pglogical, does it do anything pglogical doesn't?
It seems pglogical is more feature-rich...
2. As I understand built-in logical replication in pg-10 doesn't 
support large-objects, which we use a lot. Does pglogical replicate large 
objects? I cannot find any notes about
large-objects under "Limitations and Restrictions": 
https://www.2ndquadrant.com/en/resources/pglogical/pglogical-docs/

You may do a simple test, create a table with a largeobject and try to 
read the logical stream, if it cannot represent the lo_import, lo_open, 
lowrite, lo_close (and I 'd bet they can't be
encoded) then neither pglogical (being based on the same logical 
decoding technology) will support them

The point of email-lists like this is that one may share knowledge so one 
doesn't have to test everything one self, and can build on knowledge from 
others. I'm looking for an answer from
someone who's not betting, but knows.

I gave you enough knowledge already. Here's some more :
- go and install 10
- create a table containing one col with type oid (large object) and one 
bytea
- follow the simple setup here : 
https://www.postgresql.org/docs/10/static/logicaldecoding-example.html
- insert a row
- Do again : SELECT * FROM pg_logical_slot_get_changes('regression_slot', 
NULL, NULL);

Do you see any of your oid image data in the output? Do you see any of the bytea ? (the answer 
here in 9.5 is  "no"/"yes").
If in 10.0 is still the case, then you should think about moving to bytea.

Hm, it turns out it's not quite that simple...
Test-case:
create table drus(id bigint primary key, lo oid, data bytea);
SELECT * FROM pg_create_logical_replication_slot('my_slot', 'test_decoding');
INSERT INTO drus (id, lo, data) values(1, lo_import('/tmp/faktura_27.pdf'), 
decode('AAAEEE', 'hex'));

select * from drus;
┌┬─┬──┐
│ id │   lo│   data   │
├┼─┼──┤
│  1 │ 2873269 │ \xaaaeee │
└┴─┴──┘


SELECT * FROM pg_logical_slot_get_changes('my_slot', NULL, NULL);
┌┬──┬┐
│lsn │ xid  │  data 
 │
├┼──┼┤
│ B/E585B858 │ 9391 │ BEGIN 9391
 │
│ B/E586BE78 │ 9391 │ table public.drus: INSERT: id[bigint]:1 lo[oid]:2873269 
data[bytea]:'\xaaaeee' │
│ B/E586BF80 │ 9391 │ COMMIT 9391   
 │
└┴──┴┘
(3 rows)

So far so good, the oid-value (2873269) is apparently in the change-set, but...

If the data itself of the LO are not there then this is not so good.

Set up publication:
CREATE PUBLICATION bolle FOR ALL TABLES;
CREATE PUBLICATION

=== ON REPLICA ===
# create table on replica:
create table drus(id bigint primary key, lo oid, data bytea);
# create subscription:
CREATE SUBSCRIPTION mysub CONNECTION 'host=localhost port=5433 user=andreak 
dbname=fisk' PUBLICATION bolle;
NOTICE:  created replication slot "mysub" on publisher
CREATE SUBSCRIPTION
2017-06-22 16:38:34.740 CEST [18718] LOG:  logical replication apply worker for 
subscription "mysub" has started
2017-06-22 16:38:34.747 CEST [18720] LOG:  logical replication table synchronization worker for 
subscription "mysub", table "drus" has started
2017-06-22 16:38:35.746 CEST [18720] LOG:  logical replication table synchronization worker for 
subscription "mysub", table "drus" has finished

Looks good:
select * from drus;
┌┬─┬──┐
│ id │   lo│   data   │
├┼─┼──┤
│  1 │ 2873269 │ \xaaaeee │
└┴─┴──┘
(1 row)

...until :
SELECT lo_export(drus.lo, '/tmp/faktura.pdf') from drus where id = 1;
2017-06-22 16:40:04.967 CEST [18657] ERROR:  large object 2873269 does not exist
2017-06-22 16:40:04.967 CEST [18657] STATEMENT:  SELECT lo_export(drus.lo, 
'/tmp/faktura.pdf') from drus where id = 1;
ERROR:  large object 2873269 does not exist

So, the OID-value is replicated but pg_largeobject is empty:
select * from pg_largeobject;
┌──┬┬──┐
│ loid │ pageno │ data │
├──┼┼──┤

Re: [GENERAL] pglogical vs. built-in logical replication in pg-10

[Andreas Joseph Krogh]

På torsdag 22. juni 2017 kl. 15:25:20, skrev Achilleas Mantzios <
ach...@matrix.gatewaynet.com >:
On 22/06/2017 13:38, Andreas Joseph Krogh wrote:
På torsdag 22. juni 2017 kl. 11:43:02, skrev Achilleas Mantzios <
ach...@matrix.gatewaynet.com >:
On 22/06/2017 11:21, Andreas Joseph Krogh wrote:
Hi.
 
1. Why should one prefer built-in logical replication in pg-10 to pglogical, 
does it do anything pglogical doesn't?
It seems pglogical is more feature-rich...
2. As I understand built-in logical replication in pg-10 doesn't support 
large-objects, which we use a lot. Does pglogical replicate large objects? I 
cannot find any notes about large-objects under "Limitations and Restrictions": 
https://www.2ndquadrant.com/en/resources/pglogical/pglogical-docs/ 

 You may do a simple test, create a table with a largeobject and try to read 
the logical stream, if it cannot represent the lo_import, lo_open, lowrite, 
lo_close (and I 'd bet they can't be encoded) then neither pglogical (being 
based on the same logical decoding technology) will support them
    
The point of email-lists like this is that one may share knowledge so one 
doesn't have to test everything one self, and can build on knowledge from 
others. I'm looking for an answer from someone who's not betting, but knows.
 I gave you enough knowledge already. Here's some more :
 - go and install 10
 - create a table containing one col with type oid (large object) and one bytea
 - follow the simple setup here : 
https://www.postgresql.org/docs/10/static/logicaldecoding-example.html 

 - insert a row
 - Do again : SELECT * FROM pg_logical_slot_get_changes('regression_slot', 
NULL, NULL);

 Do you see any of your oid image data in the output? Do you see any of the 
bytea ? (the answer here in 9.5 is  "no"/"yes").
 If in 10.0 is still the case, then you should think about moving to bytea.  
Hm, it turns out it's not quite that simple...
 
Test-case:
 
create table drus(id bigint primary key, lo oid, data bytea);
SELECT * FROM pg_create_logical_replication_slot('my_slot', 'test_decoding');
INSERT INTO drus (id, lo, data) values(1, 
lo_import('/tmp/faktura_27.pdf'), decode('AAAEEE', 'hex'));

select * from drus; 
┌┬─┬──┐ 
 │ id │   lo    │   data   │
 ├┼─┼──┤
 │  1 │ 2873269 │ \xaaaeee │
 └┴─┴──┘


SELECT * FROM pg_logical_slot_get_changes('my_slot', NULL, NULL); 
 
┌┬──┬┐
 │    lsn │ xid  │  data 
 │
 
├┼──┼┤
 │ B/E585B858 │ 9391 │ BEGIN 9391 
│
 │ B/E586BE78 │ 9391 │ table public.drus: INSERT: id[bigint]:1 lo[oid]:2873269 
data[bytea]:'\xaaaeee' │
 │ B/E586BF80 │ 9391 │ COMMIT 9391 
   │
 
└┴──┴┘
 (3 rows)

  
So far so good, the oid-value (2873269) is apparently in the change-set, but...
 
Set up publication:
CREATE PUBLICATION bolle FOR ALL TABLES; 
 CREATE PUBLICATION

 === ON REPLICA ===
 
# create table on replica:
create table drus(id bigint primary key, lo oid, data bytea);
 
# create subscription:
CREATE SUBSCRIPTION mysub CONNECTION 'host=localhost port=5433 user=andreak 
dbname=fisk' PUBLICATION bolle;
NOTICE:  created replication slot "mysub" on publisher 
 CREATE SUBSCRIPTION
2017-06-22 16:38:34.740 CEST [18718] LOG:  logical replication apply worker 
for subscription "mysub" has started
 2017-06-22 16:38:34.747 CEST [18720] LOG:  logical replication table 
synchronization worker for subscription "mysub", table "drus" has started
 2017-06-22 16:38:35.746 CEST [18720] LOG:  logical replication table 
synchronization worker for subscription "mysub", table "drus" has finished

 Looks good:
select * from drus; 
 ┌┬─┬──┐
 │ id │   lo    │   data   │
 ├┼─┼──┤
 │  1 │ 2873269 │ \xaaaeee │
 └┴─┴──┘
 (1 row)

  
...until :
 
SELECT lo_export(drus.lo, '/tmp/faktura.pdf') from drus where id = 1; 
 2017-06-22 16:40:04.967 CEST [18657] ERROR:  large object 2873269 does not 
exist
 2017-06-22 16:40:04.967 CEST [18657] STATEMENT:  SELECT lo_export(drus.lo, 
'/tmp/faktura.pdf') from drus where id = 1;
 ERROR:  large object 2873269 does not exist

 So, the OID-value is replicated but pg_largeobject is empty:
 
select * from pg_largeobject; 
 ┌──┬┬──┐
 │ loid │ pageno │ data │
 ├──┼┼──┤
 └──┴┴──┘
 (0 

Re: [GENERAL] pglogical vs. built-in logical replication in pg-10

[Achilleas Mantzios]

On 22/06/2017 13:38, Andreas Joseph Krogh wrote:

På torsdag 22. juni 2017 kl. 11:43:02, skrev Achilleas Mantzios 
>:

On 22/06/2017 11:21, Andreas Joseph Krogh wrote:

Hi.
1. Why should one prefer built-in logical replication in pg-10 to 
pglogical, does it do anything pglogical doesn't?
It seems pglogical is more feature-rich...
2. As I understand built-in logical replication in pg-10 doesn't support 
large-objects, which we use a lot. Does pglogical replicate large objects? I 
cannot find any notes about large-objects
under "Limitations and Restrictions": 
https://www.2ndquadrant.com/en/resources/pglogical/pglogical-docs/

You may do a simple test, create a table with a largeobject and try to read 
the logical stream, if it cannot represent the lo_import, lo_open, lowrite, 
lo_close (and I 'd bet they can't be
encoded) then neither pglogical (being based on the same logical decoding 
technology) will support them

The point of email-lists like this is that one may share knowledge so one doesn't have to test everything one self, and can build on knowledge from others. I'm looking for an answer from someone 
who's not betting, but knows.

I gave you enough knowledge already. Here's some more :
- go and install 10
- create a table containing one col with type oid (large object) and one bytea
- follow the simple setup here : 
https://www.postgresql.org/docs/10/static/logicaldecoding-example.html
- insert a row
- Do again : SELECT * FROM pg_logical_slot_get_changes('regression_slot', NULL, 
NULL);

Do you see any of your oid image data in the output? Do you see any of the bytea ? (the answer here 
in 9.5 is  "no"/"yes").
If in 10.0 is still the case, then you should think about moving to bytea.


Thanks.
--
*Andreas Joseph Krogh*
CTO / Partner - Visena AS
Mobile: +47 909 56 963
andr...@visena.com 
www.visena.com 




--
Achilleas Mantzios
IT DEV Lead
IT DEPT
Dynacom Tankers Mgmt

Re: [GENERAL] pglogical vs. built-in logical replication in pg-10

[Andreas Joseph Krogh]

På torsdag 22. juni 2017 kl. 11:43:02, skrev Achilleas Mantzios <
ach...@matrix.gatewaynet.com >:
On 22/06/2017 11:21, Andreas Joseph Krogh wrote:
Hi.
 
1. Why should one prefer built-in logical replication in pg-10 to pglogical, 
does it do anything pglogical doesn't?
It seems pglogical is more feature-rich...
2. As I understand built-in logical replication in pg-10 doesn't support 
large-objects, which we use a lot. Does pglogical replicate large objects? I 
cannot find any notes about large-objects under "Limitations and Restrictions": 
https://www.2ndquadrant.com/en/resources/pglogical/pglogical-docs/ 

 You may do a simple test, create a table with a largeobject and try to read 
the logical stream, if it cannot represent the lo_import, lo_open, lowrite, 
lo_close (and I 'd bet they can't be encoded) then neither pglogical (being 
based on the same logical decoding technology) will support them
    
The point of email-lists like this is that one may share knowledge so one 
doesn't have to test everything one self, and can build on knowledge from 
others. I'm looking for an answer from someone who's not betting, but knows.
 
Thanks.
 
-- Andreas Joseph Krogh
CTO / Partner - Visena AS
Mobile: +47 909 56 963
andr...@visena.com 
www.visena.com 
 


 

Re: [GENERAL] pglogical vs. built-in logical replication in pg-10

[Achilleas Mantzios]

On 22/06/2017 11:21, Andreas Joseph Krogh wrote:

Hi.
1. Why should one prefer built-in logical replication in pg-10 to pglogical, 
does it do anything pglogical doesn't?
It seems pglogical is more feature-rich...
2. As I understand built-in logical replication in pg-10 doesn't support large-objects, which we use a lot. Does pglogical replicate large objects? I cannot find any notes about large-objects under 
"Limitations and Restrictions": https://www.2ndquadrant.com/en/resources/pglogical/pglogical-docs/
You may do a simple test, create a table with a largeobject and try to read the logical stream, if it cannot represent the lo_import, lo_open, lowrite, lo_close (and I 'd bet they can't be encoded) 
then neither pglogical (being based on the same logical decoding technology) will support them.

--
*Andreas Joseph Krogh*
CTO / Partner - Visena AS
Mobile: +47 909 56 963
andr...@visena.com 
www.visena.com 




--
Achilleas Mantzios
IT DEV Lead
IT DEPT
Dynacom Tankers Mgmt

Re: [GENERAL] pglogical cross subscribe

[Andy Colson]

On 8/3/2016 8:27 PM, Andy Colson wrote:

Hi all.

I have a localdb and a remotedb.

A) I'd like to send table1 and table2 from localdb to remotedb.
B) I'd like to send table3 from remotedb to localdb.

I have PG9.5 and pglogical setup, and (A) works fine.

Well, worked.  I then tried to set up (B) which seems to work, but now
(A) is broken.



Since pglogical wont work, I dropped part (B) and went back to just (A).

To implement part (B) I figured I could schedule a perl script to pull 
changes.



On remote db I:
select pg_create_logical_replication_slot('custom_slot','decoder_raw');

And wrote myself a perl script to run in a cron job every hour that would:
SELECT * FROM pg_logical_slot_get_changes('custom_slot', null, null);

and send it to localdb.

Super.  Except pg_xlog grows and grows.  pg_replication_slots shows it 
as active=false, and restart_lsn never changes.  Even after calling 
pg_logical_slot_get_changes many times.


If I: select pg_drop_replication_slot('custom_slot');

pg_xlog shrinks right away.

Does that mean I cannot poll pg_logical_slot_get_changes()?  Do I have 
to use something like pg_recvlogical or pglogical?



Thanks for your time,

-Andy


--
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] pglogical cascading replication (chaining replication)

[Nick Babadzhanian]

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:

select * from pg_replication_origin;

will show all origins on p2, find the origin for p1;

on p3:

select pg_replication_origin_create('[origin name]');

Discussed here:

https://github.com/2ndQuadrant/pglogical/issues/23

Please ignore previous message;

Regards,
Nick.


-- 
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] pglogical cascading replication (chaining replication)

[Nick Babadzhanian]

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:



Discussed here:

https://github.com/2ndQuadrant/pglogical/issues/23


-- 
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] pglogical cascading replication (chaining replication)

[Nick Babadzhanian]

I already tried to contact them, but no luck so far.

Although it seems to me that the change-set is actually forwarded, its the 
decoding that is failing on the receiving host. Check the log output for p2 and 
p3 in my previous message.

Regards,
Nick.

- Original Message -
From: "Joshua D. Drake" <j...@commandprompt.com>
To: "Nick Babadzhanian" <n...@cobra.ru>, "pgsql-general" 
<pgsql-general@postgresql.org>
Sent: Wednesday, July 13, 2016 7:16:30 PM
Subject: Re: [GENERAL] pglogical cascading replication (chaining replication)

On 07/12/2016 07:20 AM, Nick Babadzhanian wrote:
> I apologize if this is wrong place to ask the question.
>
> A quote from pglogical FAQ:
>
>> Q. Does pglogical support cascaded replication?
>> Subscribers can be configured as publishers as well thus cascaded 
>> replication can be achieved
>> by forwarding/chaining (again no failover though).
>
> The only mentions of forwarding on documentation page are:
>
>> Cascading replication is implemented in the form of changeset forwarding.
>
>> forward_origins - array of origin names to forward, currently only supported 
>> values are empty
>> array meaning don't forward any changes that didn't originate on provider 
>> node, or "{all}"
>> which means replicate all changes no matter what is their origin, default is 
>> "{all}"
>
> So my question is how to forward changeset using pglogical?

That's a great question. I have tried to figure out that information as 
well. Unfortunately it appears that it is locked up in 2ndQuadrant's 
head. I suggest contacting them.

Sincerely,

JD

-- 
Command Prompt, Inc.  http://the.postgres.company/
 +1-503-667-4564
PostgreSQL Centered full stack support, consulting and development.
Everyone appreciates your honesty, until you are honest with them.


-- 
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] pglogical cascading replication (chaining replication)

[Joshua D. Drake]

On 07/12/2016 07:20 AM, Nick Babadzhanian wrote:

I apologize if this is wrong place to ask the question.

A quote from pglogical FAQ:


Q. Does pglogical support cascaded replication?
Subscribers can be configured as publishers as well thus cascaded replication 
can be achieved
by forwarding/chaining (again no failover though).


The only mentions of forwarding on documentation page are:


Cascading replication is implemented in the form of changeset forwarding.



forward_origins - array of origin names to forward, currently only supported 
values are empty
array meaning don't forward any changes that didn't originate on provider node, or 
"{all}"
which means replicate all changes no matter what is their origin, default is 
"{all}"


So my question is how to forward changeset using pglogical?


That's a great question. I have tried to figure out that information as 
well. Unfortunately it appears that it is locked up in 2ndQuadrant's 
head. I suggest contacting them.


Sincerely,

JD

--
Command Prompt, Inc.  http://the.postgres.company/
+1-503-667-4564
PostgreSQL Centered full stack support, consulting and development.
Everyone appreciates your honesty, until you are honest with them.


--
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] pglogical cascading replication (chaining replication)

[Nick Babadzhanian]

After checking logs I noticed this error on p3-node:

>ERROR:  cache lookup failed for replication origin 
>'pgl_test_node_p1_provider_sub_p1_t06410f8'

pgl_test_node_p1_provider_sub_p1_t06410f8 is origin for p1-node.

Here are the logs from all three server (this happens every time I insert 
something into p1 table):

p1:

>LOG:  starting pglogical supervisor
>LOG:  starting pglogical database manager for database test
>LOG:  starting logical decoding for slot 
>"pgl_test_node_p1_provider_sub_p1_t06410f8"
>DETAIL:  streaming transactions committing after 0/3BDBFD0, reading WAL from 
>0/3BDBFD0
>LOG:  logical decoding found consistent point at 0/3BDBFD0
>DETAIL:  There are no running transactions.

p2:

>LOG:  starting pglogical supervisor
>LOG:  starting pglogical database manager for database test
>LOG:  starting apply for subscription sub_p1_to_p2_insert_only
>LOG:  starting logical decoding for slot 
>"pgl_test_node_p2_9face77_sub_p2_t6fd19a3"
>DETAIL:  streaming transactions committing after 0/35DD958, reading WAL from 
>0/35DD958
>LOG:  logical decoding found consistent point at 0/35DD958
>DETAIL:  There are no running transactions.
>LOG:  starting logical decoding for slot 
>"pgl_test_node_p2_9face77_sub_p2_t6fd19a3"
>DETAIL:  streaming transactions committing after 0/35DDA38, reading WAL from 
>0/35DDA00
>LOG:  logical decoding found consistent point at 0/35DDA00
>DETAIL:  There are no running transactions.
>LOG:  could not receive data from client: Connection reset by peer
>LOG:  unexpected EOF on standby connection
>LOG:  starting logical decoding for slot 
>"pgl_test_node_p2_9face77_sub_p2_t6fd19a3"
>DETAIL:  streaming transactions committing after 0/35DDA38, reading WAL from 
>0/35DDA00
>LOG:  logical decoding found consistent point at 0/35DDA00
>DETAIL:  There are no running transactions.
>LOG:  could not receive data from client: Connection reset by peer
>LOG:  unexpected EOF on standby connection 

p3:

>LOG:  starting pglogical supervisor
>LOG:  starting pglogical database manager for database test
>LOG:  starting apply for subscription sub_p2_to_p3_insert_only
>ERROR:  cache lookup failed for replication origin 
>'pgl_test_node_p1_provider_sub_p1_t06410f8'
>LOG:  worker process: pglogical apply 13294:1876007473 (PID 14180) exited with 
>exit code 1
>LOG:  starting apply for subscription sub_p2_to_p3_insert_only
>ERROR:  cache lookup failed for replication origin 
>'pgl_test_node_p1_provider_sub_p1_t06410f8'
>LOG:  worker process: pglogical apply 13294:1876007473 (PID 14189) exited with 
>exit code 1 

- Original Message -
From: "Nick Babadzhanian" 
To: "pgsql-general" 
Sent: Tuesday, July 12, 2016 5:20:59 PM
Subject: pglogical cascading replication (chaining replication)

I apologize if this is wrong place to ask the question.

A quote from pglogical FAQ:

> Q. Does pglogical support cascaded replication?
> Subscribers can be configured as publishers as well thus cascaded replication 
> can be achieved
> by forwarding/chaining (again no failover though).

The only mentions of forwarding on documentation page are:

> Cascading replication is implemented in the form of changeset forwarding.

> forward_origins - array of origin names to forward, currently only supported 
> values are empty 
> array meaning don't forward any changes that didn't originate on provider 
> node, or "{all}" 
> which means replicate all changes no matter what is their origin, default is 
> "{all}"

So my question is how to forward changeset using pglogical?

Here's my setup:

There are 3 identical CentOS 7 servers: p1, p2 and p3. Postgres version is 
9.5.3.

p1:

select pglogical.create_node
(
node_name := 'node_p1_provider',
dsn := 'host=192.168.1.101 port=5432 dbname=test'
);

select pglogical.replication_set_add_all_tables('default_insert_only', 
array['public']);

p2:

select pglogical.create_node(
node_name := 'node_p2_provider_and_subscriber',
dsn := 'host=192.168.1.102 port=5432 dbname=test'
);

select pglogical.replication_set_add_all_tables('default_insert_only', 
array['public']);

select pglogical.create_subscription
(
subscription_name => 'sub_p1_to_p2_insert_only', 
provider_dsn => 'host=192.168.1.101 port=5432 dbname=test', 
replication_sets => array['default_insert_only']
);

p3:

select pglogical.create_node(
node_name := 'node_p3_subscriber',
dsn := 'host=192.168.1.103 port=5432 dbname=test'
);

select pglogical.create_subscription
(
subscription_name => 'sub_p2_to_p3_insert_only', 
provider_dsn => 'host=192.168.1.102 port=5432 dbname=test', 
replication_sets => array['default_insert_only']
);

Result:
p1:

insert into public.test (col1) values (1);
select count(1) from public.test; -- returns 1;

p2:
insert into public.test (col1) values (2);
select count(1) from public.test; -- returns 2;

p3:
select count(1) from public.test; -- returns 1;

Expected:
p3 recieves all inserts, thus the count on p3 

Re: [GENERAL] pglogical

[Simon Riggs]

On 25 May 2016 at 18:26, Igor Neyman  wrote:

> This page:
>
> http://2ndquadrant.com/en/resources/pglogical/
>
> states that “It has also been submitted to PostgreSQL core as a candidate
> for inclusion in PostgreSQL 9.6.”
>
>
>
> So, my question is: did pglogical make the 9.6 core, or not?
>

pglogical is not in core for 9.6, though we have concrete plans for logical
replication to be in core for 10.0.


> The reason I’m asking is that pglogical is available (for 9.4 and 9.5) on
> various Linux platforms, and I’m stuck with Windows, hence the question.
>
> If it didn’t make 9.6 core, is there plan to include it in 9.7, or may be
> pglogical becomes available on Windows?
>
>
Currently pglogical does not support Windows.

It's free software, so funding for any new features or requirements is
always welcome.

-- 
Simon Riggshttp://www.2ndQuadrant.com/

PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Re: [GENERAL] pglogical

[David G. Johnston]

On Wed, May 25, 2016 at 1:26 PM, Igor Neyman  wrote:

> This page:
>
> http://2ndquadrant.com/en/resources/pglogical/
>
> states that “It has also been submitted to PostgreSQL core as a candidate
> for inclusion in PostgreSQL 9.6.”
>
>
>
> So, my question is: did pglogical make the 9.6 core, or not?
>
> The reason I’m asking is that pglogical is available (for 9.4 and 9.5) on
> various Linux platforms, and I’m stuck with Windows, hence the question.
>
> If it didn’t make 9.6 core, is there plan to include it in 9.7, or may be
> pglogical becomes available on Windows?
>
>
>
​It is not in 9.6

Whether it makes it into the next release, which will be 10.0, ​is
difficult to predict.  You are free to peruse the public discussions on
these lists, mostly on -hackers, regarding the feature if you need
something more concrete.

​At a very high level I'd think that core would be much happier if the
standalone pglogical worked on Windows instead of having the only Windows
related work occur within the development process of the core-submitted
patch.  But I am not familiar with the current state to know if that has
already been somehow addressed.

David J.
​

Re: [GENERAL] pglogical two way replication problem

[alexey.i.la...@gmail.com]

Hi,

Does anybody use pglogical
(http://2ndquadrant.com/en/resources/pglogical/)  in production or in
lab?
Is there any community around this project? Where can I register issue
and contribute?  

-- 
Best Regards,
Alexey Larin



On Mon, 2016-03-21 at 11:31 +0300, alexey.i.la...@gmail.com wrote:

> Hi All,
> 
> Try to configure pglogical in such way:
> srv1, srv2: CentOS 6.7, PostgreSQL 9.5.1, pglogical 1.0.1
> 
> On both servers created database "xdray", schema is common and
> consists tables t1 and t2. 
> The srv1 writes to the t1. The t1 added to replication set repset_t1
> on the srv1. 
> The srv2 writes to the t2. The t2 added to replication set repset_t2
> on the srv2.
> The srv1 subscribes on repset_t2.
> The srv2 subscribes on repset_t1. 
> 
> 
> 
>   SRV1  SRV2
> +--+   +--+
> |  repset_t1   |   |  |
> | +-+  |   |  |
> | |t1   +->t1 |
> | +-+  |   |  |
> |  |   |   repset_t2  |
> |  |   |  --+ |
> | t2<-+t2   | |
> |  |   |  +-+ |
> +--+   +--+
> 
> 
> Commands for reproduce. 
> 
> 
> On Srv1
> 
> $ psql xdray
> xdray=# create table t1 (id serial constraint pk_t1 primary key);
> xdray=# create table t2 (id serial constraint pk_t2 primary key);
> xdray=# select pglogical.create_node('srv1','host=srv1 user=xdray 
> dbname=xdray');
> xdray=# select pglogical.create_replication_set('repset_t1');
> xdray=# select pglogical.replication_set_add_table('repset_t1', 'public.t1');
> 
> On Srv2
> 
> $ psql xdray
> xdray=# create table t1 (id serial constraint pk_t1 primary key);
> xdray=# create table t2 (id serial constraint pk_t2 primary key);
> xdray=# select pglogical.create_node('srv2','host=srv2 user=xdray 
> dbname=xdray');
> xdray=# select pglogical.create_replication_set('repset_t2');
> xdray=# select pglogical.replication_set_add_table('repset_t2', 'public.t2');
> 
> 
> 
> On Srv1
> 
> xdray=# select pglogical.create_subscription(
>   subscription_name := 'sub_t2',
>   provider_dsn := 'host=srv2 user=xdray dbname=xdray',
>   replication_sets := ARRAY['repset_t2'],
>   synchronize_structure := false,
>   synchronize_data := true);
> 
> On Svr2
> 
> xdray=# select pglogical.create_subscription(
>   subscription_name := 'sub_t1',
>   provider_dsn := 'host=srv1  user=xdray dbname=xdray',
>   replication_sets := ARRAY['repset_t1'],
>   synchronize_structure := false,
>   synchronize_data := true);
> 
> 
> So far, so good.
> But as soon as we commit first transactions on any "producer" tables
> we have: 
> 
> 
> On Srv1
> xdray=# insert into t1 default values;
> 
> On log file of Srv1 there are end less errors like:
> < 2016-03-21 11:04:26.836 MSK >LOG:  worker process: pglogical apply 
> 16385:1317353735 (PID 31952) exited with exit code 1
> < 2016-03-21 11:04:26.838 MSK >LOG:  starting apply for subscription sub_t2
> < 2016-03-21 11:04:26.844 MSK >ERROR:  cache lookup failed for replication 
> origin 'pgl_xdray_srv1_sub_t1'
> < 2016-03-21 11:04:26.845 MSK >LOG:  worker process: pglogical apply 
> 16385:1317353735 (PID 31953) exited with exit code 1
> < 2016-03-21 11:04:26.847 MSK >LOG:  starting apply for subscription sub_t2
> < 2016-03-21 11:04:26.853 MSK >ERROR:  cache lookup failed for replication 
> origin 'pgl_xdray_srv1_sub_t1'
> < 2016-03-21 11:04:26.854 MSK >LOG:  worker process: pglogical apply 
> 16385:1317353735 (PID 31954) exited with exit code 1
> < 2016-03-21 11:04:26.856 MSK >LOG:  starting apply for subscription sub_t2
> < 2016-03-21 11:04:26.862 MSK >ERROR:  cache lookup failed for replication 
> origin 'pgl_xdray_srv1_sub_t1'
> 
> On Srv2 log:
> < 2016-03-21 11:04:26.837 MSK >LOG:  could not receive data from client: 
> Connection reset by peer
> < 2016-03-21 11:04:26.837 MSK >LOG:  unexpected EOF on standby connection
> < 2016-03-21 11:04:26.840 MSK >LOG:  connection received: host=192.168.0.104 
> port=42966
> < 2016-03-21 11:04:26.842 MSK >LOG:  replication connection authorized: 
> user=xdray
> < 2016-03-21 11:04:26.844 MSK >LOG:  starting logical decoding for slot 
> "pgl_xdray_srv2_sub_t2"
> < 2016-03-21 11:04:26.844 MSK >DETAIL:  streaming transactions committing 
> after 0/39E1060, reading WAL from 0/39E1028
> < 2016-03-21 11:04:26.844 MSK >LOG:  logical decoding found consistent point 
> at 0/39E1028
> < 2016-03-21 11:04:26.844 MSK >DETAIL:  There are no running transactions.
> < 2016-03-21 11:04:26.847 MSK >LOG:  could not receive data from client: 
> Connection reset by peer
> < 2016-03-21 11:04:26.847 MSK >LOG:  unexpected EOF on standby connection
> < 2016-03-21 11:04:26.849 MSK >LOG:  connection received: host=192.168.0.104 
> port=42967
> < 2016-03-21 11:04:26.851 MSK >LOG:  replication connection authorized: 
> user=xdray
> <