On 05/29/2015 11:07 AM, Andres Freund wrote:
> 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.
Well, I wouldn't mind a solution for drop table and drop database,
either. I'm pretty sure that's on our TODO list.
Oh, I see the confusion. When I say "time-critical", I was referring to
the situation where someone is running out of disk space. Not coming up
with a patch. AFAIK, hardly anyone is using replication slots, still.
>
> Note that all of this is 9.4 code, not 9.5.
Yes, but I'm not suggesting backporting it, just maybe a backported doc
patch.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com