On Wed, Aug 29, 2018 at 9:39 AM, Masahiko Sawada <sawada.m...@gmail.com> wrote: > 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. >
Attached a new version patch incorporated the all comments I got. Regards, -- Masahiko Sawada NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center
v6-0001-Copy-function-for-logical-and-physical-replicatio.patch
Description: Binary data
