Re: Need Force flag for pg_drop_replication_slot()

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: Need Force flag for pg_drop_replication_slot()
Дата
Msg-id 20150529180734.GA26863@alap3.anarazel.de
обсуждение исходный текст
Ответ на Re: Need Force flag for pg_drop_replication_slot()  (Josh Berkus <josh@agliodbs.com>)
Ответы Re: Need Force flag for pg_drop_replication_slot()  (Stephen Frost <sfrost@snowman.net>)
Список pgsql-hackers
On 2015-05-29 10:53:30 -0700, Josh Berkus wrote:
> On 05/29/2015 10:45 AM, Stephen Frost wrote:
> So, here's they scenario:
> 
> 1. you're almost out of disk space due to a replica falling behind, like
> down to 16mb left.  Or maybe you are out of disk space.
> 
> 2. You need to drop the laggy replication slots in a hurry to get your
> master working again.
> 
> 3. Now you have to do this timing-sensitive two-stage drop to make it work.

How is this measurably worse than trying to truncate a log table that
has grown too large? That's often harder to fight actually, because
there's dozens of other processes that might be using the relation?  In
one case you don't have wait ordering, but only one locker, in the other
case you have multiple waiters, and to benefit from wait ordering you
need multiple sessions.

Again, I'm not against improving either situation, it's just that the
urgency argument doesn't seem worth its weight.


Note that all of this is 9.4 code, not 9.5.



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Josh Berkus
Дата:
Сообщение: Re: Need Force flag for pg_drop_replication_slot()
Следующее
От: Tom Lane
Дата:
Сообщение: Re: fsync-pgdata-on-recovery tries to write to more files than previously