On Mon, Dec 7, 2020 at 6:20 AM Craig Ringer <craig.rin...@enterprisedb.com> wrote: > > On Sat, 5 Dec 2020, 10:03 Amit Kapila, <amit.kapil...@gmail.com> wrote: >> >> On Fri, Dec 4, 2020 at 7:12 PM Ashutosh Bapat >> <ashutosh.bapat....@gmail.com> wrote: >> >> I think the problem is not that the changes are visible after COPY >> rather it is that we don't have a mechanism to restart if it crashes >> after COPY unless we do all the sync up in one transaction. Assume we >> commit after COPY and then process transaction-by-transaction and it >> errors out (due to connection loss) or crashes, in-between one of the >> following transactions after COPY then after the restart we won't know >> from where to start for that relation. This is because the catalog >> (pg_subscription_rel) will show the state as 'd' (data is being >> copied) and the slot would have gone as it was a temporary slot. But >> as mentioned in one of my emails above [1] we can solve these problems >> which Craig also seems to be advocating for as there are many >> advantages of not doing the entire sync (initial copy + stream changes >> for that relation) in one single transaction. It will allow us to >> support decode of prepared xacts in the subscriber. Also, it seems >> pglogical already does processing transaction-by-transaction after the >> initial copy. The only thing which is not clear to me is why we >> haven't decided to go ahead initially and it would be probably better >> if the original authors would also chime-in to at least clarify the >> same. > > > It's partly a resource management issue. > > Replication origins are a limited resource. We need to use a replication > origin for any sync we want to be durable across restarts. > > Then again so are slots and we use temp slots for each sync. > > If a sync fails cleanup on the upstream side is simple with a temp slot. With > persistent slots we have more risk of creating upstream issues. But then, so > long as the subscriber exists it can deal with that. And if the subscriber no > longer exists its primary slot is an issue too. >
I think if the only issue is slot clean up, then the same exists today for the slot created by the apply worker (or which I think you are referring to as a primary slot). This can only happen if the subscriber goes away without dropping the subscription. Also, if we are worried about using up too many slots then the slots used by tablesync workers will probably be freed sooner. > It'd help if we could register pg_shdepend entries between catalog entries > and slots, and from a main subscription slot to any extra slots used for > resynchronization. > Which catalog entries you are referring to here? > And I should write a patch for a resource retention summarisation view. > That would be great. >> >> I am not sure why but it seems acceptable to original authors that the >> data of transactions are visibly partially during the initial >> synchronization phase for a subscription. > > > I don't think there's much alternative there. > I am not sure about this. I think it is primarily to allow some more parallelism among apply and sync workers. One primitive way to achieve parallelism and don't have this problem is to allow apply worker to wait till all the tablesync workers are in DONE state. Then we will never have an inconsistency problem or the prepared xact problem. Now, surely if large copies are required for multiple relations then we would delay a bit to replay transactions partially by the apply worker but don't know how much that matters as compared to transaction visibility issue and anyway we would have achieved the maximum parallelism by allowing copy via multiple workers. -- With Regards, Amit Kapila.
