Re: Using MyDatabaseId in SET_LOCKTAG_APPLY_TRANSACTION

From: Maxim Orlov <orlovmg(at)gmail(dot)com>
To: "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com>
Cc: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Using MyDatabaseId in SET_LOCKTAG_APPLY_TRANSACTION
Date: 2025-12-04 09:52:25
Message-ID: CACG=ezasdryCbzaW1Kg+ecskg2o+QGurbbWKG4yN1054BBy4BQ@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, 3 Dec 2025 at 15:27, Hayato Kuroda (Fujitsu) <
kuroda(dot)hayato(at)fujitsu(dot)com> wrote:

> Dear Maxim,
>
> I recalled my post [1]. The database id is helpful when we output lock
> information by DescribeLockTag(). Since it would be called when the system
> might
> be under the deadlock, any locks should not be acquired even AccessShare.
> It can
> be done if catcache is missed.
>
> OK, now I get it. Thank you very much for the explanation.

--
Best regards,
Maxim Orlov.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Maxim Orlov 2025-12-04 10:03:23 Re: POC: make mxidoff 64 bits
Previous Message Yilin Zhang 2025-12-04 09:40:57 Re:Re: pg_recvlogical: Prevent flushed data from being re-sent after restarting replication