On Thu, Jan 25, 2024 at 4:44 AM Sasmit Utkarsh <utkarshsasmit@xxxxxxxxx> wrote:
Okay Thanks. Also please help me understand the below scenariosFrom 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
