On Thu, Jan 25, 2024 at 4:44 AM Sasmit Utkarsh <utkarshsas...@gmail.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 >
