On 31 March 2017 at 01:16, Andres Freund <andres@anarazel.de> wrote:
> On 2017-03-29 08:01:34 +0800, Craig Ringer wrote:
>> On 28 March 2017 at 23:22, Andres Freund <andres@anarazel.de> wrote:
>>
>> >> --- a/doc/src/sgml/protocol.sgml
>> >> +++ b/doc/src/sgml/protocol.sgml
>> >> @@ -2034,6 +2034,8 @@ The commands accepted in walsender mode are:
>> >> <para>
>> >> Drops a replication slot, freeing any reserved server-side resources. If
>> >> the slot is currently in use by an active connection, this command fails.
>> >> + If the slot is a logical slot that was created in a database other than
>> >> + the database the walsender is connected to, this command fails.
>> >> </para>
>> >> <variablelist>
>> >> <varlistentry>
>> >
>> > Shouldn't the docs in the drop database section about this?
>>
>> DROP DATABASE doesn't really discuss all the resources it drops, but
>> I'm happy to add mention of replication slots handling.
>
> I don't think that's really comparable, because the other things aren't
> global objects, which replication slots are.
Fine by me.
Patch fix-slot-drop-docs.patch, upthread, adds the passage
+
+ <para>
+ Active <link linkend="logicaldecoding-replication-slots">logical
+ replication slots</> count as connections and will prevent a
+ database from being dropped. Inactive slots will be automatically
+ dropped when the database is dropped.
+ </para>
to the notes section of the DROP DATABASE docs; that should do the
trick. I'm not convinced it's worth going into the exceedingly
unlikely race with concurrent slot drop, and we don't seem to in other
places in the docs, like the race you mentioned with connecting to a
db as it's being dropped.
-- Craig Ringer http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services