On Fri, Nov 4, 2022 at 7:35 PM houzj.f...@fujitsu.com <houzj.f...@fujitsu.com> wrote: > > On Friday, November 4, 2022 4:07 PM Amit Kapila <amit.kapil...@gmail.com> > wrote: > > > > On Thu, Nov 3, 2022 at 6:36 PM houzj.f...@fujitsu.com > > <houzj.f...@fujitsu.com> wrote: > > > > > > Thanks for the analysis and summary ! > > > > > > I tried to implement the above idea and here is the patch set. > > > > > > > Few comments on v42-0001 > > =========================== > > Thanks for the comments. > > > > > 10. > > + winfo->shared->stream_lock_id = parallel_apply_get_unique_id(); > > + winfo->shared->transaction_lock_id = parallel_apply_get_unique_id(); > > > > Why can't we use xid (remote_xid) for one of these and local_xid (one > > generated > > by parallel apply) for the other? ... ... > > I also considered using xid for these locks, but it seems the objsubid for the > shared object lock is 16bit while xid is 32 bit. So, I tried to generate a > unique 16bit id > here. >
Okay, I see your point. Can we think of having a new lock tag for this with classid, objid, objsubid for the first three fields of locktag field? We can use a new macro SET_LOCKTAG_APPLY_TRANSACTION and a common function to set the tag and acquire the lock. One more point related to this is that I am suggesting classid by referring to SET_LOCKTAG_OBJECT as that is used in the current patch but do you think we need it for our purpose, won't subscription id and xid can uniquely identify the tag? -- With Regards, Amit Kapila.
