Thank you for the opinion.
At Tue, 28 Feb 2017 12:42:32 +0900, Michael Paquier <michael.paquier@gmail.com> wrote in
<CAB7nPqQm0QetoShggQnn4bLFd9oXKKHG7RafBP3Krno62=ORww@mail.gmail.com>
> Please no. Replication slots are designed the current way because we
> don't want to have to use something like wal_keep_segments as it is a
> wart, and this applies as well for replication slots in my opinion. If
> a slot is bloating WAL and you care about your Postgres instance, I
> would recommend instead that you use a background worker that does
> monitoring of the situation based on max_wal_size for example, killing
> the WAL sender associated to the slot if there is something connected
> but it is frozen or it cannot keep up the pace of WAL generation, and
> then dropping the slot.
It is doable without a plugin and currently we are planning to do
in the way (Maybe such plugin would be unacceptable..). Killing
walsender (which one?), removing the slot and if failed.. This is
the 'steps rather complex' and fragile.
> You may want to issue a checkpoint in this
> case as well to ensure that segments get recycled. But anyway, if you
> reach this point of WAL bloat, perhaps that's for the best as users
> would know about it because backups would get in danger.
Yes, but at the end it is better than that a server just stops
with a PANIC.
> For some applications, that is acceptable, but you could always
> rely on monitoring slots and kill them on sight if
> needed.
Another solution would be that removing a slot kills
corresponding walsender. What do you think about this?
pg_drop_replication_slot(name, *force*)
force = true kills the walsender runs on the slot.
> That's as well more flexible than having a parameter
> that basically is just a synonym of max_wal_size.
I thought the same thing first, max_wal_size_hard, that limits
the wal size including extra (other than them for the two
checkpoig cycles) segments.
regards,
--
Kyotaro Horiguchi
NTT Open Source Software Center