Re: Single transaction in the tablesync worker? - Mailing list pgsql-hackers
From | Peter Smith |
---|---|
Subject | Re: Single transaction in the tablesync worker? |
Date | |
Msg-id | CAHut+Pvj5C72R9_39TkbtB==KZuUCLmrB=EMe0E1duhyPtwVKg@mail.gmail.com Whole thread Raw |
In response to | Re: Single transaction in the tablesync worker? (Amit Kapila <amit.kapila16@gmail.com>) |
Responses |
Re: Single transaction in the tablesync worker?
Re: Single transaction in the tablesync worker? |
List | pgsql-hackers |
On Sat, Jan 23, 2021 at 11:26 PM Amit Kapila <amit.kapila16@gmail.com> wrote: > > On Sat, Jan 23, 2021 at 4:55 AM Peter Smith <smithpb2250@gmail.com> wrote: > > > > PSA the v18 patch for the Tablesync Solution1. > > > > Few comments: > ============= > 1. > - * So the state progression is always: INIT -> DATASYNC -> SYNCWAIT -> > - * CATCHUP -> SYNCDONE -> READY. > + * So the state progression is always: INIT -> DATASYNC -> > + * (sync worker FINISHEDCOPY) -> SYNCWAIT -> CATCHUP -> SYNCDONE -> READY. > > I don't think we need to be specific here that sync worker sets > FINISHEDCOPY state. > This was meant to indicate that *only* the sync worker knows about the FINISHEDCOPY state, whereas all the other states are either known (assigned and/or used) by *both* kinds of workers. But, I can remove it if you feel that distinction is not useful. > 4. > - /* > - * To build a slot name for the sync work, we are limited to NAMEDATALEN - > - * 1 characters. We cut the original slot name to NAMEDATALEN - 28 chars > - * and append _%u_sync_%u (1 + 10 + 6 + 10 + '\0'). (It's actually the > - * NAMEDATALEN on the remote that matters, but this scheme will also work > - * reasonably if that is different.) > - */ > - StaticAssertStmt(NAMEDATALEN >= 32, "NAMEDATALEN too small"); /* for sanity */ > - slotname = psprintf("%.*s_%u_sync_%u", > - NAMEDATALEN - 28, > - MySubscription->slotname, > - MySubscription->oid, > - MyLogicalRepWorker->relid); > + /* Calculate the name of the tablesync slot. */ > + slotname = ReplicationSlotNameForTablesync( > + MySubscription->oid, > + MyLogicalRepWorker->relid); > > What is the reason for changing the slot name calculation? If there is > any particular reasons, then we can add a comment to indicate why we > can't include the subscription's slotname in this calculation. > The subscription slot name may be changed (e.g. ALTER SUBSCRIPTION) and so including the subscription slot name as part of the tablesync slot name was considered to be: a) possibly risky/undefined, if the subscription slot_name = NONE b) confusing, if we end up using 2 different slot names for the same tablesync (e.g. if the subscription slot name is changed before a sync worker is re-launched). And since this subscription slot name part is not necessary for uniqueness anyway, it was removed from the tablesync slot name to eliminate those concerns. Also, the tablesync slot name calculation was encapsulated as a separate function because previously (i.e. before v18) it was used by various other cleanup codes. I still like it better as a function, but now it is only called from one place so we could put that code back inline if you prefer it how it was.. ---- Kind Regards, Peter Smith. Fujitsu Australia
pgsql-hackers by date: