Re: Need Force flag for pg_drop_replication_slot()

From: Andres Freund <andres(at)anarazel(dot)de>
To: Josh Berkus <josh(at)agliodbs(dot)com>
Cc: Stephen Frost <sfrost(at)snowman(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgreSQL(dot)org>
Subject: Re: Need Force flag for pg_drop_replication_slot()
Date: 2015-05-29 18:07:34
Message-ID: 20150529180734.GA26863@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2015-05-29 18:15:48 Re: fsync-pgdata-on-recovery tries to write to more files than previously
Previous Message Josh Berkus 2015-05-29 18:02:53 Re: Need Force flag for pg_drop_replication_slot()