Missing RHEL rpm(pg_catcheck-10) in postgres 10 repo.

[Kaliappa, Karthic]

Hello team,

We are looking to upgrade our application from postgres 9.5 to 10x, but we are 
unable to find the RPM named 'pg_catcheck-10x' for Redhat:  
https://download.postgresql.org/pub/repos/yum/10/redhat/rhel-6.7-x86_64/
We request your help in getting this rpm to the repo.

Thanks,
Karthic.

Infinite replication loop with pglogical

[Peter J. Holzer]

[I'm not sure whether this is the right list to discuss third party
extensions like 2ndQuadrant's pglogical. If there is a better place,
feel free to direct me to it]

We are testing bidirectional replication with pglogical:

Node 1: 
postgresql-9.6   9.6.6-1.pgdg90+1
postgresql-9.6-pglogical 2.1.0-1.jessie+1
Node 2:
postgresql-1010.1-1.pgdg90+1
postgresql-10-pglogical  2.1.0-1.stretch+1

(They are on different versions because we wanted to test a staggered
upgrade)

We have configured bidirectional replication on several tables. In
general that seems to work fine. When a row is inserted/updated/
deleted on one node, it is replicated to the other.

But now I seem to have triggered a replication loop:

wds=> select id, source_id, insert_ts, start_ts, update_ts, finished_ts, 
module_id, status_id, status_msg, pid, username from qualitygate.jobs where id 
= 19142008;
id| source_id | insert_ts  | start_ts | update_ts | 
finished_ts | module_id | status_id | status_msg | pid | username 
--+---++--+---+-+---+---++-+--
 19142008 | 9 | 2017-12-07 11:39:09.904071 |  |   | 
|80 | 0 ||   0 | hjp
(1 row)

wds=> select id, source_id, insert_ts, start_ts, update_ts, finished_ts, 
module_id, status_id, status_msg, pid, username from qualitygate.jobs where id 
= 19142008;
id| source_id | insert_ts  |  start_ts  
| update_ts  | finished_ts | module_id | status_id | status_msg 
| pid  | username 
--+---++++-+---+---++--+--
 19142008 | 9 | 2017-12-07 11:39:09.904071 | 2017-12-07 11:39:09.914616 
| 2017-12-07 11:39:09.914616 | |80 | 0 |
| 6863 | hjp
(1 row)

wds=> select id, source_id, insert_ts, start_ts, update_ts, finished_ts, 
module_id, status_id, status_msg, pid, username from qualitygate.jobs where id 
= 19142008;
id| source_id | insert_ts  |  start_ts  
| update_ts |finished_ts| module_id | status_id 
| status_msg | pid | username 
--+---+++---+---+---+---++-+--
 19142008 | 9 | 2017-12-07 11:39:09.904071 | 2017-12-07 11:39:09.914616 
| 2017-12-07 11:39:09.95925 | 2017-12-07 11:39:09.95925 |80 | 0 
||  -1 | hjp
(1 row)

Subsequent selects randomly return one of three states for this row
(other rows are stable). The order above is the "logical order", i.e.
the row was first inserted with the first state, then updated to the
second, and finally to the third. 

I suspect that the updates are bounced between the two nodes eternally
overwriting each other and never reaching a stable state. 

Has anybody seen this? If so, is there a way to reliably avoid this?
(Maybe with a different pglogical.conflict_resolution setting, but if it
was a conflict, I should see something in the logs, right?)

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: PGP signature

Re: Infinite replication loop with pglogical

[Peter J. Holzer]

On 2017-12-07 14:41:31 +0100, Peter J. Holzer wrote:
> We are testing bidirectional replication with pglogical:
[...]
> We have configured bidirectional replication on several tables. In
> general that seems to work fine. When a row is inserted/updated/
> deleted on one node, it is replicated to the other.
> 
> But now I seem to have triggered a replication loop:
[...]
> Subsequent selects randomly return one of three states for this row
> (other rows are stable). The order above is the "logical order", i.e.
> the row was first inserted with the first state, then updated to the
> second, and finally to the third. 
> 
> I suspect that the updates are bounced between the two nodes eternally
> overwriting each other and never reaching a stable state. 
> 
> Has anybody seen this? If so, is there a way to reliably avoid this?
> (Maybe with a different pglogical.conflict_resolution setting, but if it
> was a conflict, I should see something in the logs, right?)

This paragraph from
https://github.com/2ndQuadrant/pglogical/blob/master/README.md#subscription-management
looks relevant:

| * 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 (this is useful for two-way
| replication between the nodes), or "{all}" which means replicate all
| changes no matter what is their origin, default is "{all}"

I didn't change the default, so that means that each change is
replicated back to the originator. I guess that doesn't matter if it
happens before the next change (then the change is essentially a noop
and won't be replicated again), but it does trigger a loop if the row
has changed (because then it is changed again, which means that the
previous change will trigger another replication, and so on.)

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: PGP signature

Re: replication terminated by primary server

[Payal Singh]

On Wed, Dec 6, 2017 at 8:07 AM, Bruyninckx Kristof <
kristof.bruynin...@cegeka.com> wrote:

>
>
> In our environment, we have a master slave replication setup that has been
> working stable for the last year.
>
> Host systems are debian Jessie and we are using postgres 9.4.
>
> Now recently we have experienced a crash/hung master, and after restarting
> the postgress services on here the replication stopped working. The master
> however is running seemingly normal, except for the errors reported when it
> got restarted. After this nothing error related is reported.
>

Might want to check the master postgres logs during and after crash as
well. Also, check for wal file progress on master (select * from
pg_stat_archiver).

-- 
Payal Singh
Graduate Student
Department of Computer Science and Electrical Engineering
University of Maryland, Baltimore County

Re: ERROR: too many dynamic shared memory segments

[Thomas Munro]

On Tue, Dec 5, 2017 at 1:18 AM, Jakub Glapa  wrote:
> I see that the segfault is under active discussion but just wanted to ask if
> increasing the max_connections to mitigate the DSM slots shortage is the way
> to go?

Hi Jakub,

Yes.  In future releases this situation will improve (maybe we'll
figure out how to use one DSM segment for all the gather nodes in your
query plan, and maybe it'll be moot anyway because maybe we'll be able
to use a Parallel Append for queries like yours so that it uses the
same set of workers over all the child plans instead of the
fork()-fest you're presumably seeing).  For now your only choice, if
you want that plan to run, is to crank up max_connections so that the
total number of concurrently executing Gather nodes is less than about
64 + 2 * max_connections.  There is also a crash bug right now in the
out-of-slots case as discussed, fixed in the next point release, but
even with that fix in place you'll still need a high enough
max_connections setting to be sure to be able to complete the query
without an error.

Thanks for the report!

-- 
Thomas Munro
http://www.enterprisedb.com

Re: ERROR: too many dynamic shared memory segments

[Jakub Glapa]

Thank You Thomas!



--
regards,
Jakub Glapa

On Thu, Dec 7, 2017 at 10:30 PM, Thomas Munro  wrote:

> On Tue, Dec 5, 2017 at 1:18 AM, Jakub Glapa  wrote:
> > I see that the segfault is under active discussion but just wanted to
> ask if
> > increasing the max_connections to mitigate the DSM slots shortage is the
> way
> > to go?
>
> Hi Jakub,
>
> Yes.  In future releases this situation will improve (maybe we'll
> figure out how to use one DSM segment for all the gather nodes in your
> query plan, and maybe it'll be moot anyway because maybe we'll be able
> to use a Parallel Append for queries like yours so that it uses the
> same set of workers over all the child plans instead of the
> fork()-fest you're presumably seeing).  For now your only choice, if
> you want that plan to run, is to crank up max_connections so that the
> total number of concurrently executing Gather nodes is less than about
> 64 + 2 * max_connections.  There is also a crash bug right now in the
> out-of-slots case as discussed, fixed in the next point release, but
> even with that fix in place you'll still need a high enough
> max_connections setting to be sure to be able to complete the query
> without an error.
>
> Thanks for the report!
>
> --
> Thomas Munro
> http://www.enterprisedb.com
>