From: | Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Copy function for logical replication slots |
Date: | 2018-08-31 05:03:48 |
Message-ID: | CAD21AoBxE8ok4a_xnZ=UV0K=O5OF+gu208zGP__=TR9SNFARZA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Aug 29, 2018 at 9:39 AM, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
> On Tue, Aug 28, 2018 at 10:34 PM, Michael Paquier <michael(at)paquier(dot)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
Attachment | Content-Type | Size |
---|---|---|
v6-0001-Copy-function-for-logical-and-physical-replicatio.patch | application/octet-stream | 40.1 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Kyotaro HORIGUCHI | 2018-08-31 05:52:06 | Re: BUG #15346: Replica fails to start after the crash |
Previous Message | Amit Khandekar | 2018-08-31 04:35:05 | Re: TupleTableSlot abstraction |