On Thu, Jan 25, 2024 at 5:44 AM Sasmit Utkarsh
wrote:
> Therefore, locks acquired in one process (or transaction) do not directly
> affect locks in another process (or transaction).
>
Ummaybe if you describe the exact problem you are trying to solve with
advisory locks, we can find the best
On Thu, Jan 25, 2024 at 4:44 AM Sasmit Utkarsh
wrote:
> Okay Thanks. Also please help me understand the below scenarios
>
> From the above statement, I understand is (please correct if I'm wrong
> here), When we fork a client process, each process gets its own database
> connection or
Okay Thanks. Also please help me understand the below scenarios
>From the above statement, I understand is (please correct if I'm wrong
here), When we fork a client process, each process gets its own database
connection or transaction context. Therefore, locks acquired in one process
(or
> On Jan 24, 2024, at 19:17, Sasmit Utkarsh wrote:
>
> Need your support on understanding advisory locks in Postgresql and what is
> the best practice to have advisory locks and unlocks to work properly when we
> have multiple process forked from single process?
Advisory locks are a shared
Hi Postgresql Team,
Need your support on understanding advisory locks in Postgresql and what is
the best practice to have advisory locks and unlocks to work properly when
we have multiple process forked from single process? is there any option
for setting the locktype or please share a sample
