On Mon, Nov 7, 2022 at 10:02 AM Masahiko Sawada <sawada.m...@gmail.com> wrote: > > On Mon, Nov 7, 2022 at 12:58 PM Amit Kapila <amit.kapil...@gmail.com> wrote: > > > > > > 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. >
Fair point. I think if the user wants, she can join with pg_stat_subscription based on PID and find the corresponding subscription. However, if we want to identify everything via pg_locks then I think we should also mention classid or database id as field1. So, it would look like: field1: (pg_subscription's oid or current db id); field2: OID of subscription in pg_subscription; field3: local or remote xid; field4: 0/1 to differentiate between remote and local xid. -- With Regards, Amit Kapila.
