On Tue, Aug 28, 2018 at 10:34 PM, Michael Paquier <mich...@paquier.xyz> wrote: > On Tue, Aug 28, 2018 at 04:14:04PM +0900, Masahiko Sawada wrote: >> I think the copying from a slot that already reserved WAL would be >> helpful for backup cases (maybe you suggested?). Also, either way we >> need to make a safe logic of acquring and releasing the source slot >> for logical slots cases. Or you meant to restrict the case where the >> copying a slot that doesn't reserve WAL? > > I mean the latter, as-known-as there is no actual point in being able to > copy WAL which does *not* reserve WAL.
Agreed. I'll restrict that case in the next version > >>> Does it actually make sense to allow copy of temporary slots or change >>> their persistence? Those don't live across sessions so they'd need to >>> be copied in the same session which created them. >> >> I think the copying of temporary slots would be an impracticable >> feature but the changing their persistence might be helpful for some >> cases, especially copying from persistent to temporary. > > The session doing the copy of a permanent slot to the temporary slot has > to be the one also consuming it as the session which created the slot > owns it, and the slot would be dropped when the session ends. For > logical slots perhaps you have something in mind? Like copying a slot > which is not active to check where it is currently replaying, and using > the copy for sanity checks? Yeah, I imagined such case. If we want to do backup/logical decoding from the same point as the source permanent slot we might want to use temporary slots so that it will be dropped surely after that. Regards, -- Masahiko Sawada NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center
