On 12 March 2014 23:17, Michael Paquier <michael.paquier@gmail.com> wrote:
> On Thu, Mar 13, 2014 at 5:45 AM, Thom Brown <thom@linux.com> wrote:
>> On 12 March 2014 19:00, Josh Berkus <josh@agliodbs.com> wrote:
>>> All:
>>>
>>> I was just reading Michael's explanation of replication slots
>>> (http://michael.otacoo.com/postgresql-2/postgres-9-4-feature-highlight-replication-slots/)
>>> and realized there was something which had completely escaped me in the
>>> pre-commit discussion:
>>>
>>> select pg_drop_replication_slot('slot_1');
>>> ERROR: 55006: replication slot "slot_1" is already active
>>> LOCATION: ReplicationSlotAcquire, slot.c:339
>>>
>>> What defines an "active" slot?
>>>
>>> It seems like there's no way for a DBA to drop slots from the master if
>>> it's rapidly running out of disk WAL space without doing a restart, and
>>> there's no way to drop the slot for a replica which the DBA knows is
>>> permanently offline but was connected earlier. Am I missing something?
>>
>> I'm not clear on why would dropping an active replication slot would
>> solve disk space problems related to WAL. I thought it was inactive
>> slots that were the problem in this regard?
> You could still have an active slot with a standby that is not able to
> catch up AFAIK.
In that scenario, why would one wish to drop the replication slot? If
it can't keep up, dropping the replication slot would likely mean
you'd orphan the standby due to the primary no longer holding on to
the necessary WAL, and the standby is then useless. In which case, if
the standby is causing such problems, why not shut down that standby,
thereby effectively decommissioning it, then delete the slot?
--
Thom
