From: | Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp> |
---|---|
To: | peter(dot)eisentraut(at)2ndquadrant(dot)com |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Restricting maximum keep segments by repslots |
Date: | 2017-09-07 05:12:12 |
Message-ID: | 20170907.141212.227032666.horiguchi.kyotaro@lab.ntt.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hello,
At Fri, 1 Sep 2017 23:49:21 -0400, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> wrote in <751e09c4-93e0-de57-edd2-e64c4950f5e3(at)2ndquadrant(dot)com>
> I'm still concerned about how the critical situation is handled. Your
> patch just prints a warning to the log and then goes on -- doing what?
>
> The warning rolls off the log, and then you have no idea what happened,
> or how to recover.
The victims should be complaining in their log files, but, yes, I
must admit that it's extremely resembles /dev/null. And the
catastrophe comes suddenly.
> I would like a flag in pg_replication_slots, and possibly also a
> numerical column that indicates how far away from the critical point
> each slot is. That would be great for a monitoring system.
Great! I'll do that right now.
> --
> Peter Eisentraut http://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
>
Thanks.
--
Kyotaro Horiguchi
NTT Open Source Software Center
From | Date | Subject | |
---|---|---|---|
Next Message | Fabien COELHO | 2017-09-07 05:19:59 | Re: merge psql ef/ev sf/sv handling functions |
Previous Message | Masahiko Sawada | 2017-09-07 04:59:26 | Re: pgbench: Skipping the creating primary keys after initialization |