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