public inbox for [email protected]
help / color / mirror / Atom feedFrom: Tomas Vondra <[email protected]>
To: Amit Kapila <[email protected]>
Cc: Ashutosh Bapat <[email protected]>
Cc: PostgreSQL Hackers <[email protected]>
Cc: Masahiko Sawada <[email protected]>
Cc: Peter Eisentraut <[email protected]>
Subject: Re: logical decoding and replication of sequences, take 2
Date: Tue, 1 Aug 2023 17:16:02 +0200
Message-ID: <[email protected]> (raw)
In-Reply-To: <CAA4eK1+KTL+hug2-Mcmcr_nsshwaLRjRa6arW79u5R8Jx49=uQ@mail.gmail.com>
References: <[email protected]>
<CAExHW5s6kMKYHo1eQppvzZQyitvZcnAyKNU6xvbKwbPuTOXJkQ@mail.gmail.com>
<CAExHW5vHRgjWzi6zZbgCs97eW9U7xMtzXEQK+aepuzoGDsDNtg@mail.gmail.com>
<CAA4eK1+KFeHajszmqHKZuVHTM4cMgMuQ0xEnGiTaKJM-XGU-aA@mail.gmail.com>
<[email protected]>
<CAA4eK1+MuR5Hj7TOpuUoSnmE02re1KUUFTzFrah6-hejQ6z4aQ@mail.gmail.com>
<[email protected]>
<CAA4eK1KAP0BmfZG4Pcvt6=vcdWT7p5J0-MtJySPhnfj4aDYE-g@mail.gmail.com>
<CAA4eK1L+2bie=Yj5VSZqTRnoRCsvH=5sGh4bD76fnqSkLTkNLQ@mail.gmail.com>
<[email protected]>
<CAExHW5uCUSNTn421eH5d2pVDh-DM=SJ3sERsKu-aQrP6ZPh08g@mail.gmail.com>
<[email protected]>
<CAA4eK1+ZrdEy1GW3cDTYG4tyNFihGbM8SyYFKn=JFaKgxxXrRQ@mail.gmail.com>
<[email protected]>
<CAA4eK1+KTL+hug2-Mcmcr_nsshwaLRjRa6arW79u5R8Jx49=uQ@mail.gmail.com>
On 8/1/23 04:59, Amit Kapila wrote:
> On Mon, Jul 31, 2023 at 5:04 PM Tomas Vondra
> <[email protected]> wrote:
>>
>> On 7/31/23 11:25, Amit Kapila wrote:
>>> ...
>>>
>>> Yeah, I also think this needs a review. This is a sort of new concept
>>> where we don't use the LSN of the slot (for cases where copy returned
>>> a larger value of LSN) or a full_snapshot created corresponding to the
>>> sync slot by Walsender. For the case of the table, we build a full
>>> snapshot because we use that for copying the table but why do we need
>>> to build that for copying the sequence especially when we directly
>>> copy it from the sequence relation without caring for any snapshot?
>>>
>>
>> We need the slot to decode/apply changes during catchup. The main
>> subscription may get ahead, and we need to ensure the WAL is not
>> discarded or something like that. This applies even if the initial sync
>> step does not use the slot/snapshot directly.
>>
>
> AFAIK, none of these needs a full_snapshot (see usage of
> SnapBuild->building_full_snapshot). The full_snapshot tracks both
> catalog and non-catalog xacts in the snapshot where we require to
> track non-catalog ones because we want to copy the table using that
> snapshot. It is relatively expensive to build a full snapshot and we
> don't do that unless it is required. For the current usage of this
> patch, I think using CRS_NOEXPORT_SNAPSHOT would be sufficient.
>
Yeah, you may be right we don't need a full snapshot, because we don't
need to export it. We however still need a snapshot, and it wasn't clear
to me whether you suggest we don't need the slot / snapshot at all.
Anyway, I think this is "just" a matter of efficiency, not correctness.
IMHO there are bigger questions regarding the "going back" behavior
after apply restart.
regards
--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
view thread (46+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: logical decoding and replication of sequences, take 2
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox