Re: Please help: pgAdmin 4 on Amazon Linux 2

slower). If it is a very temporary problem though, this is often a > nice > compromise: > > yum-config-manager --save > --setopt=pgAdmin4.skip_if_unavailable=true > > failure: repodata/repomd.xml from pgAdmin4: [Errno 256] No more mirrors to > try. > > https://ftp.postgresql.org/pub/pgadmin/pgadmin4/yum/redhat/rhel-2-x86_64/repodata/repomd.xml: > [Errno 14] HTTPS Error 404 - Not Found > [root@a-1lxumlkkw4mu4 ~]# > > > I have no idea how to fix this. Any help would sure be appreciated. > > Blake McBride > > -- Tiemen Ruiten Infrastructure Engineer

Re: self-made certs not quite right

on path to requested target > Java has its own certificate keystore, you would need to add your certificate to it: https://tomcat.apache.org/tomcat-8.5-doc/ssl-howto.html Hope this helps. -- Tiemen Ruiten Infrastructure Engineer

Re: very high replay_lag on 3-node cluster

On Mon, Jul 22, 2019 at 11:28 AM Jehan-Guillaume (ioguix) de Rorthais < iog...@free.fr> wrote: > Hi, > > On Mon, 22 Jul 2019 11:05:57 +0200 > Tiemen Ruiten wrote: > [...] > > > Now to my current issue: I took the advice to add more monitor

Re: very high replay_lag on 3-node cluster

Anyone have an idea? Thanks very much in advance for any reply. On Fri, Jul 19, 2019 at 1:46 PM Tiemen Ruiten wrote: > Hello, > > In my previous post[1] on this list I brought up an issue with long > running checkpoints. I reduced checkpoint_timeout to a more reasonable > value

very high replay_lag on 3-node cluster

reasons for the high replay_lag? Is my storage just too slow? Are there any tunables available? [1] https://www.postgresql.org/message-id/flat/CAEkBuzeno6ztiM1g4WdzKRJFgL8b2nfePNU%3Dq3sBiEZUm-D-sQ%40mail.gmail.com [2] https://lists.clusterlabs.org/pipermail/users/2019-July/025967.html [3] https:/

Re: checkpoints taking much longer than expected

On Sun, Jun 16, 2019 at 8:57 PM Alvaro Herrera wrote: > On 2019-Jun-14, Peter J. Holzer wrote: > > > There was a discussion about ZFS' COW behaviour and PostgreSQL reusing > > WAL files not being a good combination about a year ago: > > > https://www.postgresql.org/message-id/flat/CACukRjO7DJvub8

Re: checkpoints taking much longer than expected

On Sun, Jun 16, 2019 at 7:30 PM Stephen Frost wrote: > Ok, so you want fewer checkpoints because you expect to failover to a > replica rather than recover the primary on a failure. If you're doing > synchronous replication, then that certainly makes sense. If you > aren't, then you're deciding

Re: checkpoints taking much longer than expected

On Sun, Jun 16, 2019 at 8:57 PM Alvaro Herrera wrote: > > Note that Joyent ended up proposing patches to fix their performance > problem (and got them committed). Maybe it would be useful for Tiemen > to try that code? (That commit cherry-picks cleanly on REL_11_STABLE.) > Interesting! The per

Re: checkpoints taking much longer than expected

On Fri, Jun 14, 2019 at 5:43 PM Stephen Frost wrote: > Greetings, > > * Tiemen Ruiten (t.rui...@tech-lab.io) wrote: > > checkpoint_timeout = 60min > > That seems like a pretty long timeout. > My reasoning was that a longer recovery time to avoid writes would be acceptab

checkpoints taking much longer than expected

Hello, I setup a new 3-node cluster with the following specifications: 2x Intel(R) Xeon(R) CPU E5-2630 v4 @ 2.20GHz (2*20 cores) 128 GB RAM 8x Crucial MX500 1TB SSD's FS is ZFS, the dataset with the PGDATA directory on it has the following properties (only non-default listed): NAMEPROPE