Andres Freund <and...@anarazel.de> writes: > On 2019-02-14 09:52:33 +1300, Thomas Munro wrote: >> Just to make sure I understand: it's OK for the file not to be there >> when we try to fsync it by name, because a concurrent checkpoint can >> remove it, having determined that we don't need it anymore? In other >> words, we really needed either missing_ok=true semantics, or to use >> the fd we already had instead of the name?
> I'm not yet sure that that's actually something that's supposed to > happen, I got to spend some time analysing how this actually > happens. Normally the contents of the slot should actually prevent it > from being removed (as they're newer than > ReplicationSlotsComputeLogicalRestartLSN()). I kind of wonder if that's > a bug in the drop logic in newer releases. My animal dromedary just reproduced this failure, which we've previously only seen on nightjar. https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=dromedary&dt=2019-06-26%2023%3A57%3A45 regards, tom lane
