On Mon, Nov 7, 2022 at 12:58 PM Amit Kapila <amit.kapil...@gmail.com> wrote: > > On Mon, Nov 7, 2022 at 8:26 AM Masahiko Sawada <sawada.m...@gmail.com> wrote: > > > > On Sun, Nov 6, 2022 at 3:40 PM houzj.f...@fujitsu.com > > <houzj.f...@fujitsu.com> wrote: > > > > > > On Saturday, November 5, 2022 1:43 PM Amit Kapila > > > <amit.kapil...@gmail.com> > > > > > > > > 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 = > > > > > > + winfo->shared->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? > > > > > > I agree that it could be better to have a new lock tag. Another point is > > > that > > > the remote xid and Local xid could be the same in some rare cases, so I > > > think > > > we might need to add another identifier to make it unique. > > > > > > Maybe : > > > locktag_field1 : subscription oid > > > locktag_field2 : xid(remote or local) > > > locktag_field3 : 0(lock for stream block)/1(lock for transaction) > > > > Or I think we can use locktag_field2 for remote xid and locktag_field3 > > for local xid. > > > > We can do that way as well but OTOH, I think for the local > transactions we don't need subscription oid, so field1 could be > InvalidOid and field2 will be xid of local xact. Won't that be better?
This would work. But I'm a bit concerned that we cannot identify which subscriptions the lock belongs to when checking pg_locks view. Regards, -- Masahiko Sawada Amazon Web Services: https://aws.amazon.com
