Re: [HACKERS] please?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Pablo Funes <pablo(at)cs(dot)brandeis(dot)edu>
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: [HACKERS] please?
Date: 1999-05-31 17:35:53
Message-ID: 16263.928172153@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Pablo Funes <pablo(at)cs(dot)brandeis(dot)edu> writes:
> Is it possible to do a nonblocking lock?

There is no way to do that in 6.4. I am not sure whether the MVCC
additions in 6.5 provide a way to do it or not (Vadim?).

> NOTE: I tried using PQrequestCancel but it won't
> cancel the request. It still blocks for as long
> as the lock lasts. The only way around I've found so
> far is to use PQreset. That's crude but works.

Not really --- what PQreset is really doing is disconnecting your
client from its original backend and starting a new backend. The
old backend is still there trying to get the lock; it won't notice
that you've disconnected from it until after it acquires the lock.
Obviously, this approach doesn't scale up very well... you'll soon
run out of backend processes.

A possible approach is for your clients to maintain more than one
backend connection, and use one of the backends to do the stuff
that might block while using another one to do the stuff that won't.
This would take a little more bookkeeping in the client but it seems
like a logically cleaner way to think about it.

regards, tom lane

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 1999-05-31 17:43:56 Re: [HACKERS] please?
Previous Message Tom Lane 1999-05-31 17:21:16 Re: [HACKERS] New IP address datatype