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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
