Andres, * Andres Freund (and...@anarazel.de) wrote: > On 2015-05-29 10:15:56 -0700, Josh Berkus wrote: > > pg_drop_replication_slot() can be a time-critical function when the > > master is running out of disk space because the replica is falling > > behind. > > I don't buy this argument. The same is true for DROP TABLE, TRUNCATE, > DROP DATABASE etc.
I disagree about that being the same.
> I mean, I agree it'd be convenient, but I can't see it as "critical".
Just a random thought- do we check the LOGIN attribute for replication
connections? If so, you could tweak that, but that may be an issue if
you have multiple replicas using the same role.
I'm not sure that it's *critical*, but I could see an argument for
adding this post-feature-freeze, which I'm guessing is what Josh was
getting at.
> > While I'm just doing this during testing, it could be a critical fail in
> > production. I think the simplest way to resolve this would be to add a
> > boolean flag to pg_drop_replication_slot(), which would terminate the
> > replication connection and delete the slot as a single operation.
>
> There's no "single operation" for terminating a backend *and* doing
> something...
That's a good point, we'd need to figure out how to make this actually
work reliably in the face of a very fast reconnecting process, if we're
going to do it.
Thanks!
Stephen
signature.asc
Description: Digital signature
