Re: Clarification regarding managing advisory locks in postgresql

On Thu, Jan 25, 2024 at 4:44 AM Sasmit Utkarsh <utkarshsasmit(at)gmail(dot)com>
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 transaction context.
>
So far so good

> Therefore, locks acquired in one process (or transaction) do not directly
> affect locks in another process (or transaction).
>
Not following you here. By definition, a lock impacts other processes;
that's the entire purpose. The affect other processes in that two
processes cannot take a lock on the same thing at the same time.

> Now, I'm faced with another situation where I'm using libpq in C as client
> programs and while calling some function it acquires pg_advisory_lock for
> the request with some identifier in transaction A. This can be thought
> of as “lock the operation with id = X” and then make some SQL
> requests(retrieve) from the database. During that if it forks into another
> process B,
>

Client side code should not fork and preserve connections across the fork.
This is multi-threaded access to a connection, and generally speaking you
should not have 2+ threads hitting the same connection returned from
libpq. This is undefined behavior, so that your questions below this I
suspect are moot.

merlin

>