On Fri, Jan 6, 2023 at 9:00 PM Amit Kapila wrote:
>
> On Thu, Jan 5, 2023 at 11:46 AM Masahiko Sawada wrote:
> >
> > Agreed. Attached the updated patch.
> >
>
> Thanks, the patch looks good to me. I think it would be probably good
> to backpatch this but it has the potential to break some monitor
On Thu, Jan 5, 2023 at 11:46 AM Masahiko Sawada wrote:
>
> Agreed. Attached the updated patch.
>
Thanks, the patch looks good to me. I think it would be probably good
to backpatch this but it has the potential to break some monitoring
scripts which were using the wrong columns for transaction id
On Wed, Jan 4, 2023 at 6:42 PM Amit Kapila wrote:
>
> On Wed, Jan 4, 2023 at 12:16 PM Masahiko Sawada wrote:
> >
> > It seems to be confusing and the user won't get the result even if
> > they search it by transactionid = 741. So I've attached the patch to
> > fix it. With the patch, the pg_locks
On Wed, Jan 4, 2023 at 12:16 PM Masahiko Sawada wrote:
>
> It seems to be confusing and the user won't get the result even if
> they search it by transactionid = 741. So I've attached the patch to
> fix it. With the patch, the pg_locks views shows like:
>
> locktype | database | relation | page
Hi,
I realized that pg_locks view shows the transaction id of a
speculative token lock in the database field:
postgres(1:509389)=# select * from pg_locks where locktype = 'spectoken';
locktype | database | relation | page | tuple | virtualxid |
transactionid | classid | objid | objsubid | virtu
