t 23:26:26, Adrian Klaver (adrian.kla...@aklaver.com) wrote:
On 5/25/19 11:46 AM, Jānis Pūris wrote:
> Hi Ron,
>
> I can not reproduce this error on BDR_Node_2 (it is not BDR_Node_1 as
> stated before. Typo)
>
> I've been successful in transferring the data with pg_dump on B
Hi Ron,
I can not reproduce this error on BDR_Node_2 (it is not BDR_Node_1 as
stated before. Typo)
I've been successful in transferring the data with pg_dump on BDR_Node_2
and then restoring it on Regular_Node_1. Then running "select * from
information_schema.sequences;" all is OK.
The problem w
Hi, Adrian
Apologies, it is a typo.
pg_basebackup was taken from BDR_Node_2, not BDR_Node_1
Thank you in advance.
Best regards, Janis Puris
On 25 May 2019 at 19:27:42, Adrian Klaver (adrian.kla...@aklaver.com) wrote:
I am not clear about above:
1) You removed BDR_Node_2 from cluster
2) You t
Hello,
I'm working with a 9.4-bdr cluster and want to move away from BDR tech all
together. So my idea was to follow instructions on
http://bdr-project.org/docs/stable/ to first strip the node from BDR making
it into "regular" node and then moving the data from this node to official
9.4 instance.
er , wrote:
> On 2019-04-26 18:36:12 +0200, Jānis Pūris wrote:
> > Thanks for the insight, Tom.
> >
> >
> > It's fairly obvious from the postmaster log that the client side
> > is not bothering to close the transaction it started
> >
> >
> > T
Thanks for the insight, Tom.
> It's fairly obvious from the postmaster log that the client side
> is not bothering to close the transaction it started
Thats what I was also thinking, but I've managed to reproduce it with
autocommit or commit before closing connection as well.
This is only reprod
sycopg2
• https://github.com/psycopg/psycopg2/issues/906
Med vennlig hilsen.
Best regards, Janis Puris.
Med vennlig hilsen.
Best regards, Janis Puris.
On 26 Apr 2019, 09:34 +0200, Jānis Pūris , wrote:
> Hello,
>
> I'm trying to do a simple health check for keepalived and other servi
Hello,
I'm trying to do a simple health check for keepalived and other services via a
python script and psycopg2 library. All seems to be all right, until I close
the connection, at which point a packet with TCP reset is produced.
This has become very problematic and creates extensive noise in m